James,
Thanks for the explanation. I can go into detail about why we made the
changes, and what occurred during the migration, however I'm not sure it
makes much difference at this point.
At this point, V5.1.2 looks to be the choice for moving forward and
attempting to solve my issue.
Thanks again for responding to my posts.
John Mull
Hershey Foods
John -
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
/usr/OV/newconfig/OVSNMP-RUN .
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
back.
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.
James Shanks
Tivoli (NetView for UNIX) L3 Support
"Mull, John" <jmull@HERSHEYS.COM> on 11/30/99 09:17:48 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: Re: Customizing Traps - Variable for Hostname on Generic SNMP Tra
p
James,
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
release.
I will take that under consideration to solve this little issue.
Appreciate your help.
John Mull
Hershey Foods
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
was
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
include.
If you do have 5.1.2, then just put Nvserverd_event in the class window
using
xnmtrap, and it should provide all the standard defaults, plus what you
added in
the slot mapping section.
I think the PRINTF function was fixed in 5.1.1 as well.
James Shanks
Tivoli (NetView for UNIX) L3 Support
John Mull
Information Technology & Integration
Process Technologist, Enterprise Systems Management
Hershey Foods Corp.
(717)534-7959
email:jmull@hersheys.com
Any comments or statements made are not
necessarily those of Hershey Foods Corporation
|