[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:	DECmcc user notes file. Does not replace IPMT.
Notice:	Use IPMT for problems. Newsletter location in note 6187
Moderator:	TAEC::BEROUD

Created:	Mon Aug 21 1989
Last Modified:	Wed Jun 04 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	6497
Total number of notes:	27359

3011.0. "One alarm - many actions??" by WELTM1::CRIDDLE (Graham Criddle, DS Tech Consultant, 853-4015) Mon May 18 1992 09:19

Hi...

I am investigating a customer requirement for multiple actions to be taken
on a single alarm condition being satisfied.

For example:

	If a critical alarm fires, then a mail message should be sent to a
	distribution list, a message should be broadcast on a terminal, and 
	someone should be paged (obviously this last requires some custom code)

	If a major alarm fires, a log file should be updated, and a mail message
	sent to a different distribution list...

	etc..

This is also a time factor in that different actions need to be taken depending
on whether the alarm fires in normal working hours, or outside them.

I have identified two ways of achieving this:

1) Have multiple alarms set for the same actual network event, each one to 
carry out one specific action. This should work, would be heavy in terms of 
resource, and it would be difficult to cope with different actions at different
times / days.

2) Have one alarm set for an event, but execute a custom procedure, which 
depending on the time of day/alarm type calls either the appropriate standard
MCC procedures, or custom procedures to achieve the required notification.
This would seem to work, but is non-standard, and to get the required parameters
to the MCC procedures, involves modifying the data file used when passing 
MCC alarm parameters.

Are there any other (easier) ways to achieve this (in either 1.1 or 1.2)?
Is there anything planned?

Rgds,
Graham

T.R	Title	User	Personal Name	Date	Lines
3011.1	encourage user-written .COM procedures	DADA::DITMARS	Pete	`Mon May 18 1992 15:41`	32
	I would recommend NOT having multiple rules for the same condition. Alarms was specifically designed to handle custom situations like this by providing the ability to execute a user-defined script when a rule fires. The mcc_alarms_*.com procedures provided with the kit are examples of how to write action procedures. They're certainly not intended to restrict the user as far as possible reactions to an alarm rule firing. It should be simple to write a command procedure that invokes two or more of the example procedures, as well as checking the day/time to determine whether the "normal" or "off hours" actions should be taken. You're right that the parameter usage will have to be modfied slightly. I would consider taking the out-of-the-box procedures and creating new versions that are specifically built to deal with multiple parameters, for example, assume that the parameter format is: mail_user_names\|logfilename\|broadcast_user_names and have each procedure parse its parameter out of the single parameter e.g. mail_param = f$element(0,"\|",parameter_string) log_param = f$element(1,"\|",parameter_string) broadcast_param = f$element(2,"\|",parameter_string) or just combine the "meat" of the example procedures into one procedure that does whatever the customer requires. The parameter parsing stuff could all be more trouble than its worth. You may want to just write command procedures that get the mail/broadcast/logging information from (for example) an external source (a distribution list file). This would give the customer additional flexibility because if the set of interested parties changes, the rule itself wouldn't have to be re-created, as is presently necessary.
3011.2		TOOK::FONSECA	I heard it through the Grapevine...	`Wed May 20 1992 17:13`	7
	Another alternative would be to use a utility like DELIVER which watches mail, and then executes commands based on mail received. (This more on the kludgy end then Pete's suggestion, but there may be situations where it has benefits.) I believe DELIVER is in the Toolshed. Since it was written outside of DEC I think it is public domain. -Dave