On problem #1:
If you use Trap Settings to alter the Description field of a Node Up or
Node Down trap to say "$3 $T" rather than just "$3", do you not get a
non-zero positive value that gets larger the longer netmon has been up? I
do.
If so, then I'd say that PJ26077 is fixed. It now works in NetView NT
just as it does in NetView for UNIX.
If you get zero when running something like the event command or
nvsnmptrap, that is because they are not up long enough to show you a real
value. This value, as the documentation for $T in trapd.conf says, is
hundredths of a second since the sending application was started (assuming
this is a NetView trap).
In SNMP the time ticks value in a trap is defined as representing
hundredths of a second from the start of some "epoch", so it has to be some
whopping big integer and cannot resolve to anything else. But the actual
value is left up to each vendor to define (when does my epoch start?) and
most in fact use "since I was last started". So NetView conforms to
standards and accepted practice using SNMP. But a timestamp of this sort
is not even required in a trap by SNMP, so many vendors don't even provide
one.
As far as a human-readable timestamp in a NetView trap goes, you are
correct; this is not provided. But var 4 of a netmon trap also contains a
timestamp which could be interpreted if you are so inclined. The time
stamp there is a standard UNIX one -- the number of seconds since Jan 1,
1970 until this trap was issued. That's what netmon puts into var 4 and
you can display it if you like but you will have to translate it to
hh:mm:ss yourself. That has never been provided. But you can "eyeball"
the value by turning on logging of traps and events in NT. The trapd.log
has a similar value as the first field in the log. The difference between
the trapd.log value and the var 4 value is how long it took trapd to
receive and process the event. And the next value in the trapd.log is a
human-readable date and time stamp which represents what the big number of
seconds translates to. So if the value in var 4 is not much different than
the value in trapd.log, then you can take the trapd.log value as roughly
equivalent to when the netmon trap was actually produced. You know for a
fact how many seconds they differ by if you care to calculate it.
Since netmon does not issue his traps over the network but by a direct
socket connection to trapd, the value in trapd.log is
always a fair approximation of when the trap was actually created, give or
take a few seconds. For vendor traps that may be a different story. You
would have to look at their device logs and see what kind of delays you are
experiencing.
If you have a suggestion about how you think NetView should be changed (e.g
- we should provide a translation of the timestamp in var 4 so you can
display it in the Event Browser) then put it in a note to
netview@tivoli.com and it will be evaluated for inclusion in a future
release. But keep in mind that this would work only for NetView (netmon
for the most part) traps. There is nothing in standards which requires any
vendor to put a "seconds-since-Jan 1, 1970" value in a trap variable and
most of them don't.
Hope this helps explain things.
James Shanks
Tivoli (NetView for UNIX) L3 Support
"Adams, Raylon" <Raylon.Adams@SSA.GOV> on 04/30/99 09:07:54 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: Netview for NT patch5.1.1
Some of the defects addressed in the readme still have NOT been fixed in
release 5.1.1.
First, although it was addressed in the README that APAR PJ26077 was fixed,
the $T variable now returns a 0 instead of the expected timestamp for when
a
trap was sent. Reading the actual APAR is not very much help either,
because it does not explain (in layman's terms) how this apar was to be
resolved. The user is simply expecting a timestamp (in hours, minutes,
seconds, etc...) reflecting either when a trap was generated or received,
not an interval between the time a process was started and the time a
subsequent trap was sent. Can this be resolved?
Second, APAR PJ25237 was not addressed at all in the readme for release
5.1.1, and remains an issue. Although, as indicated in the APAR, only one
nvpager process is created, it does NOT loop through all calls until the
system is compltely recycled, at which time, upon initialization of
Netview,
the pages are executed. Can this also be resolved?
Raylon Adams
Computer Specialist
DNE/OTSO/NMPB/NMT
410-965-0410 voice
800-766-3803 pgr
raylon.adams@ssa.gov
Tech Tools.gif
Description: Compuserve GIF
|
