I have read and re-read your append and I still have difficulty understand just
what you did and why.
It is not true that all events are now Nvserverd events, though now that you
have customized things this way, I am not sure this information will do you much
good. The default trapd.conf shipped in 5.1 and 5.1.1 maps all the events
exactly as they were in the tecad_nvk6.baroc file. It is assumed you will load
the tecad_nv6k.baroc along with the nvserverd one, and that you will use a
trapd.conf which has the correct TEC defs included. You should not have had to
modify the tecad_nv6k.baroc file in any way, unless the one you were using was
not the original one shipped with TEC.
Now, I am not sure how it happened that you thought all events were Nvserverd
events, when only those without a prior definition in the tecad_nv6k.baroc were
supposed to be. I think you may have thought so because in the migration from
4.1.2 to 5.1.1, your trapd.conf would have been migrated and the new defs would
not necessarily replace your old ones, if those were customized. So for
example, if you had customized 58916865, Node Down, then your customized def
would be retained, and the new one we shipped in 5.1.1 for it would not be used.
In that case, your TEC event class would have remained blank, and you would not
pick up the changes we shipped in the default trapd.conf. To see what I am
talking about, take a look at the default one we ship in
It says that the T/EC event class for 58916865 (IBM_NVNDWN_EV) is OV_Node_Down,
and the slot map is msg=$V3,OV_status=1, which is what the old external adapter
would have sent (I believe).
But now that you have changed all this, I doubt you would want to change it
In any case, with the level of code you have, the situation is that, if you want
to modify what is sent by the adapter, then you have to invent your own TEC
event class name, and map all the variables you want sent in the slot map
section. As originally designed, the idea was that there were just two cases:
the default and your own. For your own, you had to specify everything you
wanted sent. With 5.1.2 there are three cases, the default, the default with
some additions, and your own. So you can still get what you want in 5.1.1 by
using your own class and adding that in a baroc file to TEC. If you would
rather apply 5.1.2, then please go ahead (I recommend it to everyone), but you
are not without a solution if you have to have one now.
I sincerely hope this helps.
Tivoli (NetView for UNIX) L3 Support
"Mull, John" <jmull AT HERSHEYS DOT COM> on 11/30/99 09:17:48 AM
Please respond to Discussion of IBM NetView and POLYCENTER Manager on NetView
<NV-L AT UCSBVM.UCSB DOT EDU>
To: NV-L AT UCSBVM.UCSB DOT EDU
cc: (bcc: James Shanks/Tivoli Systems)
Subject: Re: Customizing Traps - Variable for Hostname on Generic SNMP Tra
We migrated from Netview V4.1.2 to V5.1.1 in October. At the time we were
using the external adapter to forward events to TEC. We use the TEC
rulebase to do the logic to create trouble tickets, pages, etc. We found
out with V5.1.1 that every class being forwarded to TEC was now called
Nvserverd_event. Therefore we changed in xnmtrap panels the TEC event class
names to match all the old names we were using, therefore our TEC rules
would still work. Yes, I had to add all the new Nvserverd_event slot
definitions to my baroc files for the event classes such as Link_Down,
Link_Up, OV_IF_Down, Link_Down_Cisco, etc...
It appears the answer to my problem may be in the maintenance V5.1.2
I will take that under consideration to solve this little issue.
Appreciate your help.
What TEC class are you using for this and what level of NetView code are you
trying this on?
Support to allow you to add variables to the default Nvserverd_event class
not provided until 5.1.2.
If you don't have 5.1.2, then you must (a) define your own class for the TEC
event class, and (b) supply a mapping for all the variables you want to
If you do have 5.1.2, then just put Nvserverd_event in the class window
xnmtrap, and it should provide all the standard defaults, plus what you
the slot mapping section.
I think the PRINTF function was fixed in 5.1.1 as well.
Tivoli (NetView for UNIX) L3 Support