RE: [nv-l] Mib2trap

[James Shanks <jshanks@us.ibm.com>]

Well, JT, I don't know what to tell
you exactly.
When you sent the FMTCHG event you should
have seen an entry in trapd.log that it was received.  I've forgotten
the exact text but it is something like "format file changed."
If the reload was successful, then you would not see an indication of that,
but if there's anything wrong with the updated file, then you'd see an
error message trap, sent by trapd himself,  about how it could not
be loaded because of such-and-such error on line so-and-so.  It's
very specific.
But assuming that it loaded OK, it comes
down to this: trapd doesn't think that the incoming traps are defined,
and you think they are.

All I can suggest is that you gather
some data and call Support.
If trapd is running with the -x option
already, then toggle the trapd.trace on from the command line ("trapd
-T") and after you have traced a couple examples of the failure, pass
that data to Support :  your trapd.conf file, trapd.log, and trapd.trace,
and let them see what sense they can make of it.  Also include the
addtrap script you created from the MIB just for good measure, and the
MIB too.  Might as well be thorough.   If trapd is not running
with -x (and "ps -ef  | grep trapd" will tell you) then
you can set that in serversetup with hex dump all packets option.  This
gives us a hex version of the trap when we trace, so we can follow through
the formatting of it. 

  If Level 2  cannot figure
this out, and they think trapd is somehow broken, you can be sure they'll
notify me and I'll be looking too.  If the code is broken, well, then
eventually it will be my job to fix it

HTH


James Shanks
Level 3 Support  for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group