Harry Lewis
----- Ira's Note ----
jmp-owner@pwg.org on 10/14/97 06:56:07 AM
Please respond to jmp-owner@pwg.org @ internet
To: jmp@pwg.org @ internet, Harry Lewis/Boulder/IBM@ibmus
cc:
Subject: Re: JMP> jmTimeStamp
Hi Harry,
Are you suggesting that 'JmTimeStampTC' be changed to units of
'TimeTicks' like 'sysUpTime' (in MIB-II)? I think the rationale
for units of seconds was to avoid the appearance of demanding
accuracy in 'TimeTicks' for processing info on print jobs,
which is unlikely to be of use to client applications anyway.
Separately, by a poor design decision, TimeTicks was made a
fundamentally different syntax (over-the-wire) in SMIv1 and
SMIv2, so that it CAN'T be stored in an 'INTEGER' type
(in the job attribute table). So if we change the units
of 'JmTimeStampTC' to hundredths of a second, we STILL
need the TC, to avoid trying to use ACTUAL 'TimeTicks'
syntax for job attributes.
Does your implementation team think we should align the
units? While an SNMP agent may know time in 'TimeTicks',
a print language interpreter may NOT have available
such accuracy (to supply the values for job attributes).
Cheers,
- Ira McDonald (outside consultant at Xerox)
-------------------------- Harry's note --------------------------
We've run into an observation, here, regarding the units and range of T=
=3D
imeStamp
(seconds) and the range of sysUpTime.
The jmTimeStampTC can count to appx 68 years, in seconds, while sysUp=
=3D
Time
represents time in 100ths of a second and, resets appx every 1.36 years=
=3D
=