Conference azur::mcc

2787.0. "Alarm Dispatching - customer oriented" by SKIBUM::GASSMAN () Fri Apr 17 1992 13:14

    
    Bob Boyd, the moderator of the Internet Newsgroup on DECmcc wrote this
    note about alarm dispatching.  It's been discussed in this conference
    before, but I post this in case someone within engineering has an
    interest in looking into what a customer has doing about the problem,
    what their needs are, and how some synergy may develop.  Feel free to
    contact him directly at [email protected], or post directly to
    the news group noted in the FROM below...
    
    bill
    
    
From:	ENUF::DECWRL::"[email protected]" "17-Apr-1992 1208" 17-APR-1992 12:10:14.58
To:	<enuf::gassman>
CC:	
Subj:	 



Due to some needs I'm addressing at our installation I've started work on a
somewhat comprehensive DECmcc Alarm Dispatch procedure.  It will be driven
by subfields in some of the rule fields.  I'm interested in feedback about 
my design goals/plans.  One of the ideas I plan to incorporate is that 
a single rule can have multiple actions taken depending on how it got
fired.  For instance, most every rule firing should cause a log record
to be created.  Some rules won't.  Some rules will send mail.  Some will
send mail and generate an operator request.  I suspect that that's enough
to get the idea across.  

Another benefit of going this way is that it will detach the action
procedures from the rule database by 1 level -- so that I don't have to
redefine every rule that uses a particular action procedure every time 
there's a change needed (Yes I know there are workarounds -- and they
are messy too).

1st:  Has anyone already done this?  If so I would rather not re-invent it.

I'm planning to use a fairly simple approach to digesting the parameters.
Since I'm working on a VAX/VMS system right now, I plan to use DCL.  What
I'm curious about is what any of you might think about using Perl or csh
on Unix to do this and how easy it might be/not to convert.  My experience
so far says that the right way to do this stuff on Unix is with Perl or
a similar language.  Csh just doesn't make it as easy to deal with strings
as DCL.

Is there something in the DECmcc V1.2 distribution that would make this
dispatcher less interesting? 

I would really like to see the ability to have DECmcc be able to have the
value of PROCEDURE point to a DECmcc script which would cause changes in
the current session.  Some flag/indicator would be needed to distinguish
whether a procedure is a CLI script or a DECmcc script.  This would make it
possible to "program" a finite state machine with several interesting
possibilities that I would really like to be able to do.  Is this in the
works?  Should I submit a suggestion SPR on this?

Here's what I've written up so far that will document the behavior of the
dispatcher:
===============================================================================

This command procedure is a site-specific configurable alarm dispatcher.
It is driven by the parameters of the alarm.

When it is invoked, it will use recursion to force execution of the most
recent version of itself.

First it scans all of the parameters passed to it by the DECmcc Director
and parses them into useable chunks.  

Then there are several actions it can initiate based on the Parameter
setting in the alarm rule.  These are coded in a table of choices -- they
are essentially just subprocedures that are available to take various
actions.

Some possibilities:
1.  Send mail
2.  Send an operator request
3.  Log a history record
4.  Do something to the network
5.  Shut down DECmcc Session(s)
6.  Restart DECmcc Alarm/Historian/Export processes
7.  Take a snapshot of the MCC Alarms Rules
8.  Stop/Start a batch queue
9.  Shutdown/Reboot a system
10. Electrocute the network manager
11. Submit an SPR to DEC
12. TDR all of the network segments simultaneously

The Description parameter of an alarm can be either a simple text string to be
used as is or it can start with an "@" character.  If it begins with "@"
then it will be interpreted as pointing at a file to extract the text from.
In the event that MAIL is sent, the text will be processed and included in
the message.

Another possibility is to have the Severity indicator select  which action
to take.  This is done through the use a table which is coded directly into
the Select field of Parameter setting or a file name if it begins with "@".

===========================================================================

--
Bob Boyd                 
[email protected] 
Unisys/EPA               



  Bob 

  (ext. 4441) 


% ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ======
% Received: by enet-gw.pa.dec.com; id AA00409; Fri, 17 Apr 92 09:08:24 -0700
% From: [email protected]
% Received: from  (ralph.rtpnc.epa.gov) by ralph.rtpnc.epa.gov (5.65c/1.34)id AA24855; Fri, 17 Apr 1992 11:36:08 -0400
% Apparently-To: <enuf::gassman>