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
|