| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 4047.1 | no CLEAR alarm | MFRNW1::SCHUSTER | Karl Schuster @MFR Network Services | Wed Nov 11 1992 10:22 | 7 |
| I have exactly the same problem ( before with V1.2, and now still with
V1.2.3 ).
The CLEAR-Alarm notification after an alarmexception only fires
sometimes. ( A SHOW Status of the alarmrule says FALSE and CLEAR ).
I use simple comparison expressions in the rules.
Karl
|
| 4047.2 | Any answers?? | ANOSWS::COMFORT | Spent a little time on the hill | Mon Nov 16 1992 15:29 | 14 |
|
Has anyone reviewed this issue yet? This is becoming a major "Bad
Press" item for DECmcc. It would have been better had it not worked
at all, but right now the customer perceives no net increase in
functionality over V1.1, ie. the icons do not change back
automatically. I need to recommend something very quickly...the
powers that be saw it work and now are questioning why it doesn't
anymore. I can write alarms to circumvent the situation, but would
prefer to obtain a valid reason/solution for the inconsistency.
Regards,
Dave Comfort
|
| 4047.3 | May need to be escallated | TOOK::MINTZ | LKG2-2 near pole X3, cube 6072, dtn 226-5033 | Mon Nov 16 1992 15:54 | 9 |
| Well, according to note 3887, this is working as designed.
If that is the case, and the functionality does not satisfy
your customer, then please make sure the change makes the requirements
list (see NOTED::EMF_REQ, or contact product management directly).
If you believe there is a bug, then either file a QAR (internal)
or an SPR (for customers).
|
| 4047.4 | re .-1 | ANOSWS::COMFORT | Spent a little time on the hill | Mon Nov 16 1992 16:28 | 15 |
|
I believe that the situation described in 3887.* is NOT the same
situation as is documented here. In fact, I have alarms that do
change_of and I write two alarms, one for each condition so as to turn
the entity critical and clear and I realize the differences when using
this approach. I will (I guess) pursue this matter in terms of a QAR
or SPR, though I have never done this before. I do feel however that if
you read 3887 closely, then the alarm as exhibited in .0 should work
ACCORDING to the design AND documentation. And in fact it does for a
while, then fails.
Regards,
Dave Comfort
|
| 4047.5 | | TOOK::MINTZ | LKG2-2 near pole X3, cube 6072, dtn 226-5033 | Mon Nov 16 1992 17:31 | 6 |
| OK, I'll bring this back to the attention of the relevant developer.
But make sure the problem is escallated as well, since it clearly
has not been resolved by notes over the last several months.
-- Erik
|
| 4047.6 | The problem has been fixed | TRM::KWAK | | Mon Jan 11 1993 11:12 | 33 |
|
RE: .0 and previous replies.
Brad Woodcook submitted a QAR (#8 in MCC013_EXT database) on this
problem with comprehensive description.
The problem has been fixed on 1/9/93. I am attaching the answer
(editted) to the QAR.
After investigating this problem, it was found that the problem
was in 3 different modules: Alarms, DNA4_AM and Notification PM.
In case of rule transition ERROR to FALSE, the DNA4_AM was returning
different identifiers (Phase4 address and Fullname) even though the
node4 is registered, and the Alarms FM could not find the rule transition
of the node4 entity. The DNA4_AM was fixed to return the same identifiers
on both successful and unsuccessful (ERROR) evaluations.
The subentity wildcarded rules were not handled properly in Alarms FM
and Notification PM. In successful evaluations, the AM returns a
specific entity instance even if the rule expression is wildcarded
(the GE wildcard is handled by Alarms and the SE wildcard is handled by
the AM). However, in case of error (when a node is down), the AM returns
entity specifier which still contains wildcarded SE. This behaviour
prevented Alarms FM and Notification FM from generating clear event and
changing Icon's colors. The code changes have been made to both
Alarms FM and Notification PM to handle this situation.
The fixed codes have been tested and placed in the baselevel X1.3.6, and
will be included in the Field Test Update.
William
|