| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1052.1 | call it what you want... | TOOK::CALLANDER | Jill Callander DTN 226-5316 | Tue May 28 1991 11:23 | 8 |
| this is a known "restriction" within the MCC1.1 kit. The alarms only
show state=enabled from the process where the rule was enabled. From
all other locations it will show up as disabled, and with no counters.
There were a number of reasons why this was implemented in this fashion,
ranging from security issues, to base system limitations. This is QAR
#71 in the mCC_INTERNAL database. Work I believe is scheduled in this
area for V1.2 or V2.0 I am not sure, some one from that team can comment.
|
| 1052.2 | V1.2 Ultrix has it now! | WAKEME::ANIL | | Tue May 28 1991 15:01 | 18 |
| Raj,
As Jill has poited out in .1, what you observed is not a bug but a
feature of V1.1 of Alarms. :-(.
Well here is the good news. On the Ultrix implementation of DECmcc, Alarms
is always ON! Thanks to the execution model implemented by Jim Swist,
even if you exit MCC, all your (enabled) rules will remain enabled.
For agive user, the status of the rule will always reflect the correct
state of the rule. i.e. Alarms will not lie!
It is quite possible that this model will be back ported to VMS in
V1.2. No guarantees though! ;-)
So stay tunes!
- Anil Navkal
|
| 1052.3 | Always, or until reboot? | ASD::MINTZ | Erik Mintz, MS ZKO3-2/S11, dtn 381-2331 | Tue May 28 1991 15:42 | 7 |
| > Well here is the good news. On the Ultrix implementation of DECmcc, Alarms
> is always ON! Thanks to the execution model implemented by Jim Swist,
> even if you exit MCC, all your (enabled) rules will remain enabled.
At least until the system reboots, after which time someone has to manually
re-start the alarms FM, right?
|
| 1052.4 | right. | TOOK::CALLANDER | Jill Callander DTN 226-5316 | Tue May 28 1991 17:11 | 0 |
| 1052.5 | on ultrix: automatically restarted w/rules disabled? | TOOK::GUERTIN | I do this for a living -- really | Wed May 29 1991 08:39 | 18 |
| RE:.3
On Ultrix, Management Modules should not need to be restarted manually.
The "foreground" MM (almost always a PM) simply makes a request, and
the MM gets restarted automatically. The Alarms-FM does not separate
"foreground" and "background", so it does not know what the state of
the Alarms-FM process was prior to the reboot. Hence the rules (I
assume) would all be in a disabled state. Perhaps in some future
release the Alarms team could add in the capabilities of "turning on",
or "shutting off" the detection mechanism (the service portion, as
opposed to the management portion of Alarms). In this way they could
discover that the detection mechanism should still be "detecting" and
re-start it automatically (thereby enabling all the rules that should
be enabled). Naturally, they should post an MCC event saying that the
detection mechanism had to be re-started, but that is veering off the
subject a little.
-Matt.
|
| 1052.6 | Naaahhhhhh..... | TOOK::SWIST | Jim Swist LKG2-2/T2 DTN 226-7102 | Wed May 29 1991 12:23 | 16 |
| re: last few
Let us not confuse an accident of the implementation with a design
feature.
I believe that where possible MCC operations should behave the same
regardless of how management modules actually get instantiated. An MM
like alarms which has some persistent state from mcc_call to mcc_call
(and I'm talking about independent calls, not calls related by a
handle), should not rely on keeping that state in volatile memory.
On VMS you lose that state on PM exit. On Ultrix you lose it on reboot
or on killing the FM). You must make a non-volatile record of such
state so that it can be remembered regardless of process structure.
Failure to do so is a bug, not a side effect of the implementation.
|