| Olli,
I am happy to see you like CM V1.0, we hope V1.1 is even better for you.
All the documentation for V1.1 is in OPG::CM$DOCS: however, the functional
spec does not go into too much detail around what was in VCS that we are
putting in CM, take a look at the spec, and ask us here if you are unsure
about any particular feature, after all, we may have overlooked something.
Please bear in mind when doing this that Console Manager IS NOT VCS, so you
may find what appears to be features missing, the functionality for which,
with closer examination, we have implemented in a slightly different way.
Not much is said about the C3 in the functional spec, this is because we
are basically using a hybrid of what is available in V1.0 of CM and V1.4
of VCS, basically the major C3 features will give you the following :-
1) User defined Icons, we have implemented this at the expense of
the scalable Icons. Icons can be created with any X bitmap editor
such as DECW$PAINT
2) Peripherals, Lines, and Text may be added to the C3
3) Each user get his/her own C3, which only shows the systems they
have been given access to, however, each user may customize their
own C3 adding their own lines, peripherals, text etc.
4) The eventlist used by the C3 is the same as the ENS action routine,
this has the benefit of less support for us, and a consistent look
and feel for the user.
Also, there are some features implemented which do not appear in
the functional spec, these relate to ENS and the event list window...
1) An event record has a "source" field, this can be set when a user
creates a program to "poke" events into the ENS, for all Console
Manager generated events, that is internal events and events
detected by CM, this is set to "Console" (although this may change.
2) An event record has a Subsystem field, this will be used in the C3
in a future release to help us change the color of peripheral icons.
A subsystem being "Disk" or "Tape" etc.
3) The eventlist has the ability to acknowledge and clear events.
Acknowledge will merely resend an event to all running actions
(which are using the IPC communication mechanism) having first
changed the events source field to the username of the person
running the eventlist (if they run it interactively) or the
display the eventlist is being sent to (if it is run as an
action routine)
Clear performs the same function as Acknowledge, except the
priority of the event is changed to CLEAR.
When the eventlist get either an acknowledge or clear event it
will update the event currently being displayed with the new
information.
NOTE: Neither the Acknowledge or Clear events update the event
log for the system which had the original event, we plan
to do this in a future release.
Finally, if you are using POLYCENTER Frameworks, the CM editor can generate
a template registration file in order for you to easily register all of your
system consoles, along with this we will be providing an action routine which
sends events to you POLYCENTER Frameworks system.
Everything I have said here has been implemented and works today on ULTRIX,
sort of on OSF/1 and almost on OpenVMS, however, none of this is a commitment
to ship these features in the V1.1 release. (I have to say that, you never
know what will happen these days).
Cheers,
Phil
|