| Title: | POLYCENTER Console Manager |
| Notice: | Kits, Scans, Docs on CSC32:: as PCM$KITS:,PCM$DOCS:, PCM$SCANS: |
| Moderator: | CSC32::BUTTERWORTH |
| Created: | Thu Aug 06 1992 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 1541 |
| Total number of notes: | 6564 |
This problem was entered in this notesfile last fall and the bottom
line was PCM doesn't support it. At the customer's request, they would
like us to look at this issue again and see if we can come up with a
workaround - even if that means customized command files or code need to
be written. Therefore, I am looking for any suggestions on how this
might be done.
The problem
-----------
A large customer has PCM deployed in several sites and is using PCM to
remotely manage their systems. They normally have two or more C3
screens monitoring a given set of systems. As part of their
procedures, when an operator either corrects the problem or takes
ownership to correct it, the icon is reset to white on the C3 screen.
This tells the other operators that it does NOT require any further
attention. If the icon is any other color, then that means a problem
has occured and no one has done anything with it.
Note - they are using the option on the C3 to
retain the highest priority color, rather than the
color of the last error.
The problem they pointed out several months ago is that if they reset
an icon to the default neutral color on one C3 screen, it doesn't get
reset on the other screens.
This is troublesome enough when you have two or more screens in the
same data center monitoring the same systems. However, if you move
towards two or more screens in different locations monitoring the same
set of systems, the situation is out of control. This is what they
now have since they have consolidated data centers and, in general,
will have the same C3 screen up in different locations (which are in
different states and/or countries).
The are running PCM V1.7 on OpenVMS/VAX.
I realize that PCM doesn't do this (reset icon colors across multiple
C3 screens). However, I have the following questions that might help
me figure out a way to do this for them.
1) With the callable interface, is there any way that a program can be
written to tell PCM to reset the icon colors on the C3 screen? Even
if it's not a supported call, that's okay because they will pay us
(Digital) to do it and they understand it's a custom feature.
2) Is there any other way to trigger a C3 screen to clear the icon
color? I thought that we might change the option to have the icon
display the color of the LAST event and then force a low priority
event to occur. However, this won't really give us the default
white (unless we redefine one of the other colors to be white)
and it does create some additional procedural problems.
3) Is there any way to use the clear or acknowledge functions from the
ENS screens to force the C3 screen to reset the icon?
4) Any other ideas either technical or procedural?
Thanks in advance,
Larry
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 1322.1 | CSC32::BUTTERWORTH | Gun Control is a steady hand. | Thu Jun 13 1996 12:54 | 70 | |
> same data center monitoring the same systems. However, if you move
> towards two or more screens in different locations monitoring the same
> set of systems, the situation is out of control. This is what they
> now have since they have consolidated data centers and, in general,
> will have the same C3 screen up in different locations (which are in
> different states and/or countries).
Believe me, we more than understand the issue. This feature has been
officially suggested for a future release.
> I realize that PCM doesn't do this (reset icon colors across multiple
> C3 screens). However, I have the following questions that might help
> me figure out a way to do this for them.
> 1) With the callable interface, is there any way that a program can be
> written to tell PCM to reset the icon colors on the C3 screen? Even
> if it's not a supported call, that's okay because they will pay us
> (Digital) to do it and they understand it's a custom feature.
No there is not and thats the code that needs to be written into the
C3.
> 2) Is there any other way to trigger a C3 screen to clear the icon
> color?
If you mean is there a magic callable routine to clear it, no there is not.
> I thought that we might change the option to have the icon
> display the color of the LAST event and then force a low priority
> event to occur. However, this won't really give us the default
> white (unless we redefine one of the other colors to be white)
> and it does create some additional procedural problems.
This idea has merit. You could write a routine to call CMUserSendEvent
to send an event to ENS which would then send it to the various action
routines and C3's. You could make this an Indeterminate priority event
and then change the color to White. The problem is that there is no way
to make the C3 tell this application to generate the event when an icon
is reset so we are really back to square one.
> 3) Is there any way to use the clear or acknowledge functions from the
> ENS screens to force the C3 screen to reset the icon?
No, as only the Eventlist application acts on the Clear/Ack feature.
> 4) Any other ideas either technical or procedural?
The only real solution is an enhancement to the product. The hooks we
need to even hack a temporary solution just aren't there. I wished I
had better news for you but I don't.
What most sites do is use Eventlist as their main Event management
application and train their operators to just ignore the icon
colors on the C3. The Eventlist window has the same capabilities as the
C3 in terms of viewing events and their context plus it has the
Clear/Ack feature that you need. If your worry is that the operators
will kill the Eventlist and forget to bring it up via the C3 there is
an easy solution to that. Simply create a filter to dispatch the
Mutli-Line Window action to the various X-displays. Even if the
operator accidentialy kills the window, ENS will start a new one when
the next event occurs.
Regards,
Dan
Thanks in advance,
Larry
| |||||
| 1322.2 | Guess its time for Plan B | PLESIO::SOJDA | Thu Jun 13 1996 20:26 | 14 | |
Thanks, Dan. I figured as much but I wanted to get one more opinion.
My next thoughts were to use a combination of the ENS screen
capabilities plus some changes in procedures. In fact, I did discuss
using ENS as the primary control mechanism with the customer last fall
and they were at least amenable to discussing it. The issue slid down
the priority list but now has resurfaced since they began consolidating
data centers and managing things remotely.
I will post any ideas that I come up with for the benefit of any one
else with a similiar need.
Larry
| |||||