T.R | Title | User | Personal Name | Date | Lines |
---|
2309.1 | define parameters in your procedure | NSCRUE::KEANE | U.S. NIS Service Engineering and Delivery | Tue Feb 11 1992 10:51 | 72 |
|
I ran into this also. The approach that I took was to redefine p7 in my
procedure to be the parameters (ie: mail dist. list). I then call a slightly
modified mail alarm procedure, where the mail procedure sees p1 defined as the
mail dist. list and p2 as the data file which contains the rest of the alarm
information (described as p8 in the default alarm files). The procedure then
returns to do the same setup for the broadcast parameter and then the log file
entry.
Below is an example that worked during my brief testing.
$! Combined MCC alarm notification procedure
$!
$! Description:
$!
$! This file calls the standard MCC alarm notification procedures
$! so that more than one type of notification occurs when an alarm rule fires.
$! This procedure should be updated to provide valid notification parameters
$! to each of the procedures as they are called.
$!
$! The following parameters are passed from MCC when an alarm rule fires:
$!
$! Parameters:
$! p1: Rule name
$! p2: Description of rule
$! p3: Category
$! p4: Rule Expression
$! p5: Time of Detection
$! p6: Values that caused the rule to fire
$! p7: Distribution
$! - For log file notification, this is the name of the log
$! to write the alarms to.
$! - For mail notification, this is the mail address. If
$! distribution is a mailing list, p7 must be preceded by
$! a "@" character. Otherwise, it is a list of usernames
$! separated by commas.
$! - For terminal broadcast notification, this is the destination
$! of the broadcast message.
$! TERMINAL=(terminal id[,...]) |
$! USERNAME[=(username[,...])] |
$! NODE[=(node[,...])]
$! These parameters follow the conventions for the VMS
$! command REPLY. One of these three must be specified,
$! or no message will be sent.
$! p8: Data file containing information as passed in p1 through p7
$! and the Domain and Severity
$!
$!
$! The following section provides the mail notification
$!
$mail:
$ p7 := @user:[keane]test.dis
$ @mcc_common:my_alarms_mail_alarm.com -
"''p7'" "''p8'"
$!
$! The following section provides the broadcast notification
$!
$broad:
$ p7 := terminal=lta500:
$ @mcc_common:my_alarms_broadcast_alarm.com -
"''p7'" "''p8'"
$!
$! The following section provides the log file notification
$!
$log:
$ p7 := user:[keane]triple.log
$ @mcc_common:my_alarms_log_alarm.com -
"''p7'" "''p8'"
$!
$ PURGE/KEEP=3 SYS$SCRATCH:ALARM_TRIPLE_NOTIFY.LOG
$ exit
|
2309.2 | It's in the manual | TOOK::R_SPENCE | Nets don't fail me now... | Tue Feb 11 1992 10:58 | 3 |
| The parameters are described on page 4-17 of the Alarms FM Use manual.
s/rob
|
2309.3 | This works! | BSYBEE::EGOLF | John C. Egolf LKG2-2/T02 x226-7874 | Tue Feb 11 1992 12:22 | 43 |
| I don't know about V1.1, but in V1.2 P1-P7 are not used. See
the example below:
Rule:
! This rule acts on a DECnet Phase IV node, checking user bytes sent every
! 15 minutes. The icon will turn color (according to the color the user
! has defined for MAJOR severity), and will send a mail message to the
! DEMO account, using the ALARM FIRED PROCEDURE specified.
DISABLE DOMAIN LITTLETON_MASS RULE RULE-3
DELETE DOMAIN LITTLETON_MASS RULE RULE-3
CREATE DOMAIN LITTLETON_MASS RULE RULE-3 -
EXPRESSION_RULE_FORMAT_1=(NODE4 .HAWK2 User Bytes Sent > 100, -
AT EVERY 00:15:00),-
SEVERITY=MAJOR,-
ALARM FIRED PROCEDURE = [demo]mycom.com,-
ALARM FIRED PARAMETER = "DEMO,SYSTEM",CATEGORY="DECmcc Demo",-
DESCRIPTION = "Wow!, We've sent a lot of bytes!!"
[demo]mycom.com
$ @mcc_common:MCC_ALARMS_BROADCAST_ALARM.COM a b c d e f g "''p8'"
$ @mcc_common:MCC_ALARMS_MAIL_ALARM.COM a b c d e f g "''p8'"
MCC_ALARMS_BROADCAST_ALARM.COM
copy the modified MCC_ALARMS_BROADCAST_ALARM.COM from
BSYBEE::DUA0:[PUBLIC]MCC_ALARMS_BROADCAST_ALARM.COM to
MCC_COMMON:*.* on your system
Note that the ALARM FIRED PARAMETER, if it is to be used for
both mail and broadcasts can't have a node name (ie:
HAWK2::demo) or be a distribution list (ie. @allusers) unless
you really want to 'hack up' the MCC_ALARMS_BROADCAST_ALARM.COM
file.
Hope this helps...
JCE
|
2309.4 | | NSCRUE::KEANE | U.S. NIS Service Engineering and Delivery | Tue Feb 11 1992 12:42 | 9 |
|
Sorry.
I should have specified that the procedure in .1 works on V1.1 MCC. I had not
needed the same functionality under 1.2 yet.
Thanks for the clarification.
Scott
|
2309.5 | V1.2 didn't change | TOOK::R_SPENCE | Nets don't fail me now... | Tue Feb 11 1992 17:33 | 9 |
| P1-P8 are still there in V1.2 but the sample procedures don't use them.
The MCC_ALARMS_MAIL procedure for example only uses P8 to get the
data file name and then it opens the file and fetches the info from it.
Depending on what you need to do you might get some info from the
passed parameters and some from the file. Whatever works best for you.
s/rob
|