| 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 |
This has probably been referenced before, and if so , just point me in
the right direction.
I understand that alarm status and counters are instance specific, but
does this mean that a command procedure fired by an alarm, is not able
to modify the status of the alram rule that fired it . ie; disable
itself once it's been fired. , and therefore the rule has to be
disabled and deleted in order to stop the rule firing on multiple
occaisions.
Or is this what alarm filters were designed to do ?
Conrad Price
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 6181.1 | There are ways if you try hard ! | WELLIN::MCCALLUM | Thu Nov 24 1994 08:21 | 23 | |
It depends on where the alarm rule is 'running'
If it is in a users process then you cant do a lot.
If it is in a detached process with either DETmcc or the alarm
manager then you can disable it with approriate commands.
If it is in its own batch command procedure then you could stop it !
A technique often used to stop multiple notifications from repetitive
firings is to make the alarm command procedure send its notification
via a data collector message and not via an alarm fired notification.
The command procedure that runs when the alarm fires can then
check a state machine ( logical name ) to see of it has fired once
and not notify again if it has. The only trouble then is clearing
the logical which need to be done when the alarm rule is cleared,
this may need another alarm rule. If you want to see how this is done,
it is done be the mcc_reach procedures by Mr Woodcock ( now left).
There is a pointer in MCC-TOOLS
Dave.
| |||||