The thing to understand is that the event is internally generated by
Netview with a status of 'CLOSED'. It came into the T/EC that way.
(James, thanks for reminding us.)
In the rulebuilder's guide, in the overview of the architecture of the
event server, it explains how the event server validates and processes
incoming events. On the subject of status,it says:
'An event adapter can also send and event with a status of CLOSED to
indicate that a previously received event of the specified class should
have its status changed to CLOSED; the previously received event to be
closed is the most recent duplicate of the same event description. The
event being sent with a CLOSED status is dropped and not stored in
the event database."
No rules involved here, just default function. I believe this describes
just
what you are seeing. If you want these handled differently, perhaps you
could ADD a rule to handle events of that class (nvserverd) to override
the status and keep them around for a while. The nvserverd events were
coded the way they were because that is the most commonly desired
behavior.
You will see the same behavior for interface/node up/down events, except
that in those cases, since the events are normal netview events, you have
the option of overriding the status sent with the event by changing it in
the
Events configuration tec slot mapping dialog.
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit
============================================================================
If the "you" here is meant to be "me", that is "James Shanks", then the
answer
is "No, I could not explain how this works in TEC, that is why I sent you
to the
Tivoli forum where TEC is discussed."
Perhaps some other NV-L reader can.
But NetView 5.1.2 does not contain any patches or updates to TEC.
James Shanks
Tivoli (NetView for UNIX) L3 Support
Eva-Maria Fettig <efettig@HAITEC.DE> on 02/02/2000 12:08:03 PM
Please respond to Discussion of IBM NetView and POLYCENTER Manager on
NetView
<NV-L@UCSBVM.UCSB.EDU>
To: NV-L@UCSBVM.UCSB.EDU
cc: (bcc: James Shanks/Tivoli Systems)
Subject: Antwort: Re: nvserverd start/end events to tec
Could you explain the mechanism inside TEC that closed this fatal
nvserverd
event? I don't mind the event being closed but I would like to know how it
works. Usually a rule is applied against an event to close it. But there is
no
rule for this! Did I install a TEC Patch with that Netview Upgrade with
some
"hidden" rules?
I'd just like to know how it works. And it would be fine if I could see the
harmless event on the TEC console also.
Thanks
Eva
-----------------------------------------------------------------------
-----------
Eva-Maria Fettig e-mail: efettig@haitec.de
Haitec AG Tel. +49 89 35631 3393
Alois-Wolfm
üller-Str. 8 Fax +49 89 35631 3300
80939 München Mobil +49 172 8592939
-----------------------------------------------------------------------
------------
James Shanks <James_Shanks@TIVOLI.COM> am 02.02.2000 17:32:49
Bitte antworten an Discussion of IBM NetView and POLYCENTER Manager on
NetView
<NV-L@UCSBVM.UCSB.EDU>
An: NV-L@UCSBVM.UCSB.EDU
Kopie: (Blindkopie: Eva-Maria Fettig/HAITEC/DE)
Thema: Re: nvserverd start/end events to tec
Good idea, Leslie, but I am afraid it won't work in this case.
These TEC events are not traps received by trapd (which could be
manipulated in
the way that you describe) but rather, they are internally generated events
by
nvserverd. They have to be, because the "ending" message is the last thing
nvserverd sends before he goes down, and the "re-connected" message is the
first
thing he sends when he comes up. So timing requires that these not be
traps,
and besides, they probably would not make it through the customer ruleset
doing
the trap forwarding, if we made them into traps. So they are not
customizable
in that way. They aren't customizable at all.
Interestingly enough, the reconnected message was "added" in 5.1.2 to do
exactly
what the complaint was that started this thread. It was designed to remove
the
"nvserverd ending" message from the TEC event console and thereby "close
the
loop" with TEC. It had always been part of the design, it was just never
implemented until other people complained that when they recycled NetView
they
had these open events left on their TEC consoles that did not go away when
NetView came back up. I am sorry that the original poster doesn't like the
way
that this works. It was specifically designed to do just that.
James Shanks
Tivoli (NetView for UNIX) L3 Support
Leslie Clark <lclark@US.IBM.COM> on 02/02/2000 11:02:30 AM
Please respond to Discussion of IBM NetView and POLYCENTER Manager on
NetView
<NV-L@UCSBVM.UCSB.EDU>
To: NV-L@UCSBVM.UCSB.EDU
cc: (bcc: James Shanks/Tivoli Systems)
Subject: nvserverd start/end events to tec
I would go to the event configuration function and manipulate the
status that is sent with these events. The CLOSED and HARMLESS
business is set there, in the T/EC slot mapping dialog. Then you don't
have to change the rule on the T/EC server that would effect more events
than just these.
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
(248) 552-4968 Voicemail, Fax, Pager
|