f$getsyi("BOOTTIME") drift

[Jack Trachtman]

VMS V7.3-2/Alpha

Can someone with access to the VMS source listings tell me how this function gets the boot time? I run a program once a day which uses the output of this function for comparison purposes, and unless I'm going crazy, the value returned seems to change by a few seconds each day I run it - though it doesn't change if I run it multiple times immediately one after another! (My simplistic expectation was that the boot time was simply stored somewhere as a text string at boot time and would never change.)

[Hoff]

The system boot time is simply the quadword time when the box boots.

Log the value retrieved at one hour or six hour intervals, and determine if the value really does drift. (Things that "seem" are a whole lot more difficult to diagnose.)

Some drift in the system time is entirely normal; the system clock just isn't a chronograph. The saved time (the VAX TOY and the Alpha BB_WATCH) for VAX and Alpha systems can drift by 65 or by 130 seconds a month, and be in spec. The running time can drift more, depending on what is going on.)

Drift in the system boot time isn't normal.

If this is a cluster, also make sure you are running your code on the node you think you are running it upon.

[Arch_Muthiah]

Jack,

I think the boot time is saved as literal string as we know the other time literals like LOGIN, TODAY, etc. whenever we want to use this, the system's parsing function fetches this values from the internal storage and uses system's convert funtions available in different levels.

As Holf explained clearly, there will be drift in the system running time, the time difference you see may be due to the drift in the runnning system-time you stored; on any version of VMS, the BOOT value never change.


Archunan

[John Gillings]

Jack,
Fuzzy recollection...

There are some odd things that can happen with boot times and uptimes with calculations performed on different nodes in the cluster.

For a sanity check, see system cell EXE$GQ_BOOTTIME. This should be the quadword time and shouldn't change.

ANALYZE/SYSTEM
SDA> EXAMINE/TIME EXE$GQ_BOOTTIME

This should give the same results as F$GETSYI.

[Hein van den Heuvel · Accepted solution]

It's stored as binary time in EXE$GQ_BOOTTIME.
Try this:
$ANALYZE/SYS
SDA> eval EXE$GQ_BOOTTIME
Hex = FFFFFFFF.82D06460 Decimal = -2100272032 EXE$GQ_BOOTTIME
SDA> exam EXE$GQ_BOOTTIME
SDA> exam EXE$GQ_BOOTTIME/time

Now
$ write sys$output f$getsyi("BOOTTIME")
and
$ exam/hex %x82D06460
$ exam/hex %x82D06464

The text date× should match
and the binary date&time will match.

Now add the the DCL examined to the daily script and see if those values move.

I have a hard time imagining an ntp/utc scenarios where a clock adjust would influence the displyed boot time.


Archunan>> "I think the boot time is saved as literal string"
Hmmm, that would be very un-VMS
All dates are stored as 8-byte = 64-bit binary timestamps.

Regards,
Hein.

[John Gillings]

Jack,
Here's some DCL that will check the SDA value against the SYI value. No output means they are identical (I'd be astonished if they were ever different).

$ EXE$GQ_BOOTTIME=%X95F88828 ! Version specific
$ t[32,32]=F$CVUI(32,32,F$FAO("!AD",8,EXE$GQ_BOOTTIME))
$ t[0,32]=F$CVUI(0,32,F$FAO("!AD",8,EXE$GQ_BOOTTIME))
$ SDA_boottime=F$FAO("!%D",F$CVUI(32,32,F$FAO("!AD",8,t)))
$ SYI_boottime=F$GETSYI("BOOTTIME")
$ IF SDA_boottime.NES.SYI_boottime THEN SHOW SYM *_boottime

Note, this uses the V7.3-2 value for EXE$GQ_BOOTTIME, find the appropriate value for your system from SDA:

$ ANALYZE/SYSTEM
SDA> EVAL EXE$GQ_BOOTTIME

[Jack Trachtman]

Sorry I didn't close this before.

Mr. Gillings seems to be correct about the boottime value being different when examined from different nodes in a cluster.

My simple test:

for each node in a cluster, enter:

$ WRITE SYS$OUTPUT -
F$GETSYI("BOOTTIME",nodename)

The values are different depending on the node where the cmd is issued.