[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
| 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 |
3048.0. "Synchronous FCL PM ?" by BALZAC::COULON (Even if it works, ask why) Thu May 21 1992 09:27
The PROCEDURES used in an ALARM RULE must exist at the rule creation time: on
VMS, the full file specs (including file version and TRANSLATED LOGICALS) are
saved with the rules... Now, if a PROCEDURE is changed, the RULE has to be
changed too... The sample run (from the FCL PM T1.2.7) below shows that the
DISABLE RULE function is asynchronous (The message is "Normal operation will be
terminated". But when?) and generates some 'software logic error'.
Is there a 'synchronous' FCL mode?
Thanks,
Serge
MCC> SHOW MCC 0 ALARM RULE * ALL ATTR, IN DOMAIN ENGINEERING
MCC 0 ALARMS RULE RULE_1
AT 21-MAY-1992 14:08:57 All Attributes
NAME = RULE_1
State = Enabled
Substate = Running
Result of Last Evaluation = In progress
Current Severity = Critical
Creation Timestamp = 21-MAY-1992 14:05:40.32
Evaluation Error = 0
Evaluation True = 0
Evaluation False = 0
Expression = (OCCURS(COLLECTOR SEGUR ANY EVENTS))
Procedure = USER2:[COULON]MCC_BATCH.COM;3
Queue = "SYS$BATCH"
Perceived Severity = Critical
Probable Cause = Unknown
MCC> @USER2:[COULON.MCC]MCC_ALARM1
%MCC-S-VERIFYENTER, entering command procedure USER2:[COULON.MCC]MCC_ALARM1.COM;
DEFINE THE_RULE MCC 0 ALARMS RULE
%MCC-I-SYMDEF, Symbol defined.
!
SHO THE_RULE * STATE , IN DOMAIN ENGINEERING
MCC 0 ALARMS RULE RULE_1
AT 21-MAY-1992 14:09:25 Status
State = Enabled
DISABLE THE_RULE RULE_1, IN DOMAIN ENGINEERING
MCC 0 ALARMS RULE RULE_1
AT 21-MAY-1992 14:09:25
Normal operation will be terminated.
DELETE THE_RULE RULE_1, IN DOMAIN ENGINEERING
MCC 0 ALARMS RULE RULE_1
AT 21-MAY-1992 14:09:25
Enabled rules cannot be deleted.
!
CREATE THE_RULE RULE_1 -
EXPR = (OCCURS(COLLECTOR SEGUR ANY EVENTS)),-
PERC SEVERITY = CRITICAL ,-
PROC = SYS$LOGIN:MCC_BATCH.COM ,-
QUEUE = SYS$BATCH ,-
IN DOMAIN = ENGINEERING
MCC 0 ALARMS RULE RULE_1
AT 21-MAY-1992 14:09:26
Attempt to create duplicate entity rejected.
!
ENABLE THE_RULE RULE_1, IN DOMAIN ENGINEERING
MCC 0 ALARMS RULE RULE_1
AT 21-MAY-1992 14:09:26
Normal operation has begun.
SHO THE_RULE * STATE , IN DOMAIN ENGINEERING
MCC 0 ALARMS RULE RULE_1
AT 21-MAY-1992 14:09:27 Status
State = Enabled
!
%MCC-S-VERIFYEXIT, exiting command procedure USER2:[COULON.MCC]MCC_ALARM1.COM;10
SEGUR::MCC>
!!!!!!!!!!!!!! Alarm, 21-MAY-1992 14:09:27 !!!!!!!!!!!!!! [1]
Domain: PRSTRA_NS:.ENGINEERING Severity: Indeterminate
Notification Entity: MCC PRSTRA_NS:.MCC.SEGUR_DIRECTOR ALARMS RULE RULE_1
Event Source: Domain PRSTRA_NS:.ENGINEERING Rule RULE_1
Event: OSI Rule Exception
Event Type = QualityofServiceAlarm
Event Time = 21-MAY-1992 14:09:25.96
Probable Cause = Unknown
Additional Info = { (
significance = True,
information = "Software logic error
detected<EOS>%MCC-E-NOPARAMLIST,
no parameter list was supplied in
this ILV buffer" ),
(
significance = True,
information = "(OCCURS(COLLECTOR SEGUR ANY
EVENTS))" ) }
Managed Object = MCC 0 ALARMS RULE RULE_1 Perceived Severity = Indeterminate
| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 3048.1 | no synchronous mode | MCC1::DITMARS | Pete | Fri May 22 1992 18:07 | 13 |
| there are two ways to approach this:
1) get FCL to wait before doing the delete. use the AT START
qualifier to delay the DELETE slightly, e.g.
delete mcc 0 alarm rule foo, in domain x, at start +0:0:10
this should give the rule time to disable
2) use a command procedure that automatically executes the latest
version of itself. this defeats the "security" features in
alarms (which is what you're wrestling with), but it'll do what
you want.
|