|
Thanks
James, you rock!
:)
JT
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
|