| 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 |
I am receiving DNA4_EVL event messages on Ultrix such as adjacency
up/down and node reachability changes and causing rules to fire as a
result of these events. I then pick up the alarm fired parameters and
arguments from the mcc_alarms_data_<time>_<user>.dat file written to
the /tmp directory and passed as argument 1 to the shell script. I find
that these files quite often have corrupt data in them which seems to
be caused by buffers not being properly cleaned out from a previous
event. The data seems to be ok if you look at the raw event displayed
directly through notification services so I think that DECmcc itself is
getting good data from EVL. The 3 problems I have seen to date are:
(1) Managed object node number incorrect if it is shorter than the
previous one seen eg: ... 62.25 becomes 62.25 5 if the previous was
longer eg 62.102.
(2) Event argument often has text on the end belonging to other events,
when a previous event was longer eg when a node name as well as an
address was returned on an adjacency down.
(3) The time field always has Iinf on the end of it. Where does this
come from?
Here are 2 files showing these problems. Note that I have added some
carriage returns to stop the lines going off the screen. The
<---(n) shows the problem bit.
Thanks, chris.
RULE: Domain LOCAL_NS:.test Rule node4_adjacency_down_event
MANAGED_OBJECT: Node4 62.1022 Circuit QNA-0 Adjacent Node 62.25 5 <---(1)
DESCRIPTION:
CATEGORY:
EXPRESSION: (occurs(node4 * circuit * adjacent node * adjacency down))
TIME: 1992-10-13-08:07:25.160Iinf <---(3)
EVIDENCE: The last event detected: Node4 62.1022 Circuit QNA-0 Adjacent
Node 62.25 Adjacency Down 1992-10-13-08:07:25.008Iinf <---(3)
EVENT_ARGUMENTS: Event: Adjacency Down Adjacency Down Reason = Adjacency
listener receive timeout Adjacent Node Address = 62.25
PARAMETER: DECNET
SEVERITY: Major
DOMAIN: Domain LOCAL_NS:.test
RULE: Domain LOCAL_NS:.test Rule node4_adjacency_up_event
MANAGED_OBJECT: Node4 62.1022 Circuit QNA-0 Adjacent Node 62.502
DESCRIPTION:
CATEGORY:
EXPRESSION: (occurs(node4 * circuit * adjacent node * adjacency up))
TIME: 1992-10-13-07:44:40.687Iinf <---(3)
EVIDENCE: The last event detected: Node4 62.1022 Circuit QNA-0 Adjacent
Node 62.502 Adjacency up 1992-10-13-07:44:40.391Iinf <---(3)
EVENT_ARGUMENTS: Event: Adjacency up Adjacency Up Adjacent Node
Address = 62.5027:41:00.859Iinf Name = LZOPCB <---(2)
PARAMETER:DECNET^--- All of this is wrong---^---belongs to another evt
SEVERITY: Clear
DOMAIN: Domain LOCAL_NS:.test
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 3895.1 | Yes, looks like bugs | TOOK::MINTZ | LKG2-2 near pole X3, cube 6072, dtn 226-5033 | Tue Oct 13 1992 08:36 | 9 |
> (3) The time field always has Iinf on the end of it. Where does this > come from? I believe that the inf is a part of the DTSS style time spec. The other two points are QARable bugs; see note 7 for info on how to file a QAR. | |||||
| 3895.2 | QAR 500 - Is there a prize? | BAHTAT::BOND | Fri Oct 16 1992 12:07 | 3 | |
QARed as QAR 500.
Do I get a prize for submitting the 500th MCC QAR?
| |||||