VAX hardware clock question - VMS

This is a discussion on VAX hardware clock question - VMS ; Hello everyone, even if I've read more than once all the relevant comp.os.vms messages and some other online documents and FAQs, it's not very clear to me if to be safe I should do a SET TIME some time before ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: VAX hardware clock question

  1. VAX hardware clock question

    Hello everyone,

    even if I've read more than once all the relevant comp.os.vms messages
    and some other online documents and FAQs, it's not very clear to me if
    to be safe I should do a SET TIME some time before the 467th day since
    the last time I did it (no matter which day and month), or if I should
    do it anyway some time before April 11th each year, even if the system
    isn't approaching the 467 days limit.

    BTW, I do know that system time runs on its own and does not reference
    the hardware clock except during bootstrap and SET TIME.

    Thank you,
    G. (Hobbyist system manager from Italy)


  2. Re: VAX hardware clock question

    gerry77@no.spam.mail.com wrote:

    > even if I've read more than once all the relevant comp.os.vms messages
    > and some other online documents and FAQs, it's not very clear to me if
    > to be safe I should do a SET TIME some time before the 467th day since
    > the last time I did it (no matter which day and month), or if I should
    > do it anyway some time before April 11th each year, even if the system
    > isn't approaching the 467 days limit.
    >
    > BTW, I do know that system time runs on its own and does not reference
    > the hardware clock except during bootstrap and SET TIME.



    I'm going to guess at what seems to be confusing you, and have queued
    the following addition for the next edition of the OpenVMS FAQ:

    [[The SET TIME command is expected harmless (SHUTDOWN.COM issues this
    command during a controlled shutdown), though there have been reports
    where the SET TIME command processing has been seen to cause the saved
    system time to drift by a few seconds or so during its processing.

    A VAX system manager could choose to issue the SET TIME command on a
    regular schedule (eg: monthly), though it is particularly the window
    between 1-Jan and approximately 11-Apr each year that is key to this
    sequence; where the year value saved in the VAX TOY can be reset. Other
    than within this particular window, the current year matches the year
    saved in the VAX system image.

    See [4.2 Keeping the OpenVMS system time synchronized?] for how to keep
    the system time synchronized with an external time base. Some drift is
    inherent in any free-running clock.

    --

    During the OpenVMS VAX bootstrap, the system time is synthesized from
    the time and day value saved in the TOY and the year value saved in the
    VAX system image SYS.EXE.

    The SET TIME command writes the time and day value to the TOY and the
    full quadword time (including the year) into the SYS.EXE system image.]]

    --

    If the above does not address your concerns, some details on your
    confusion might be helpful.


    --
    www.HoffmanLabs.com
    Services for OpenVMS

  3. Re: VAX hardware clock question

    On Oct 28, 8:17 am, gerr...@no.spam.mail.com wrote:
    > Hello everyone,
    >
    > even if I've read more than once all the relevant comp.os.vms messages
    > and some other online documents and FAQs, it's not very clear to me if
    > to be safe I should do a SET TIME some time before the 467th day since
    > the last time I did it (no matter which day and month), or if I should
    > do it anyway some time before April 11th each year, even if the system
    > isn't approaching the 467 days limit.
    >
    > BTW, I do know that system time runs on its own and does not reference
    > the hardware clock except during bootstrap and SET TIME.
    >
    > Thank you,
    > G. (Hobbyist system manager from Italy)


    If you did a clean shutdown in the same year you can skip it.

    You can approach Apr 11th at most twice in any given 467-day period,
    so the "each year" you mentioned only happens at most twice. (I think
    it's really a 497-day period, but I'm not sure. If it's 497 then it
    would be more like May 11.)

    Consider the case in which you did your last clean shutdown or SET
    TIME Dec 31, 2005. Then the offset becomes 1-JAN-2005 and you're good
    only until approx. 11-APR-2006 or 11-MAY-2006 or so. So to be safe,
    every system must have a SET TIME run (whether done from a clean
    shutdown or not) at least once during the first few months of EVERY
    YEAR (which agrees with my first statement).

    (Note that SHUTDOWN.COM issues the command

    $SET TIME="''f$time()'"

    I think it's done this way just in case your TOYR is already out of
    sync with your system clock.)

    AEF


  4. Re: VAX hardware clock question

    On Sun, 28 Oct 2007 10:50:10 -0700, AEF
    wrote:

    > You can approach Apr 11th at most twice in any given 467-day period,
    > so the "each year" you mentioned only happens at most twice. (I think
    > it's really a 497-day period, but I'm not sure. If it's 497 then it
    > would be more like May 11.)


    TOY clock is a 32 bit counter, i.e. it can count from %X00000000 to
    %XFFFFFFFF, ticking every 10 ms. Upon SET TIME it is initialized at
    %X10000000, so we have the following (in non-leap years):

    %XFFFFFFFF - %X10000000 = %XEFFFFFFF possible 10 ms ticks (hex.)

    %XEFFFFFFF = 4,026,531,839 possible 10 ms ticks (decimal)

    24 * 3600 * 100 = 8,640,000 ticks a day

    365 * 8,640,000 = 3,153,600,000 ticks a year

    4,026,531,839 - 3,153,600,000 = 872,931,839 ticks left after 1 year

    872,931,839 / 8,640,000 = 101 (rounded) remaining days before wrap

    101 - (31 + 28 + 31) = 11 days in April before wrap :-)

    > Consider the case in which you did your last clean shutdown or SET
    > TIME Dec 31, 2005. Then the offset becomes 1-JAN-2005 and you're good
    > only until approx. 11-APR-2006 or 11-MAY-2006 or so. So to be safe,
    > every system must have a SET TIME run (whether done from a clean
    > shutdown or not) at least once during the first few months of EVERY
    > YEAR (which agrees with my first statement).


    That's a clear statement! :-)

    Bye,
    G.


  5. Re: VAX hardware clock question

    On Sun, 28 Oct 2007 11:51:55 -0400, Stephen Hoffman
    wrote:

    > A VAX system manager could choose to issue the SET TIME command on a
    > regular schedule (eg: monthly), though it is particularly the window
    > between 1-Jan and approximately 11-Apr each year that is key to this
    > sequence; where the year value saved in the VAX TOY can be reset. Other
    > than within this particular window, the current year matches the year
    > saved in the VAX system image.


    Am I right if I state the following?

    "The TOY clock is a 32 bit counter that ticks every 10 ms and counts
    the time elapsed since January 1st of a given year. Because of its
    resolution (and considering that it starts counting at %X10000000) it
    would wrap around on April 11th of the year following that of last
    reset. Thus every year between January 1st and April 11th the counter
    has to be reset to the number of ticks elapsed since January 1st of
    that particular year."

    > The SET TIME command writes the time and day value to the TOY and the
    > full quadword time (including the year) into the SYS.EXE system image.]]


    When I started investigating about this subject, I found a similar
    statement quite confusing: I was thinking that the TOY clock counted
    the time elapsed since the full date stored into SYS.EXE. I think it
    should be noted that even if the system image contains the full time
    quadword, only the year part is used to determine when the TOY counter
    started, because it is always based upon January 1st (of the year in
    SYS.EXE), no matter when it was reset.

    Bye,
    G.


    P.S.: I'm not english native, sorry for any mistake.

  6. Re: VAX hardware clock question

    Either the FAQ or Ask The Wizard (I think both are now under
    http://www.hoffmanlabs.com or on http://www.hp.com/go/vms ) have a very
    good explanation of the toy clock and what happens during boot to decide
    if the toy clock has a valid number or not. And invaliud number causes
    VMS to prompt for a new date/time.

    When booting, the system compares the TOY clock value against a value
    last stored on the system disk. Value on system disk is stored when you
    do a SET TIME from a privileged account and toy clock also is reset.

    The Toy value should always be higher than that stored on disk. The
    problem is that if you allow the toy clock to run past its bit limit, it
    goes back to zero and starts counting from there. But the last system
    time stored on disk is still a relatively high value, so if you crash
    and reboot, it will prompt you for time since the toy close is lower
    than that of system time.

  7. Re: VAX hardware clock question

    On Oct 28, 2:37 pm, gerr...@no.spam.mail.com wrote:
    > On Sun, 28 Oct 2007 10:50:10 -0700, AEF
    > wrote:
    >
    > > You can approach Apr 11th at most twice in any given 467-day period,
    > > so the "each year" you mentioned only happens at most twice. (I think
    > > it's really a 497-day period, but I'm not sure. If it's 497 then it
    > > would be more like May 11.)

    >
    > TOY clock is a 32 bit counter, i.e. it can count from %X00000000 to
    > %XFFFFFFFF, ticking every 10 ms. Upon SET TIME it is initialized at
    > %X10000000, so we have the following (in non-leap years):


    Why is it initialized to %X10000000?

    [...]

    AEF


  8. Re: VAX hardware clock question

    gerry77@no.spam.mail.com wrote:

    > When I started investigating about this subject, I found a similar
    > statement quite confusing: I was thinking that the TOY clock counted
    > the time elapsed since the full date stored into SYS.EXE. I think it
    > should be noted that even if the system image contains the full time
    > quadword, only the year part is used to determine when the TOY counter
    > started, because it is always based upon January 1st (of the year in
    > SYS.EXE), no matter when it was reset.


    There's a slight problem with the direct approach...

    If the full value in the Time Of Year (TOY) register was a direct bias
    off the full time value saved in the OpenVMS VAX system image SYS.EXE,
    then the time would be somewhere between slightly and seriously wrong
    every time you swapped a system disk, or whenever you booted standalone
    BACKUP.

    If you grab just the year from the saved value, you have a window when
    you can swap disks around without having the system time go weird.
    You'd have to reset it each time you boot a disk.

    This yearly-wrap design even feeds back into the register name. Time Of
    Year. And the acronym itself is, well, another, um, comment on the
    design. An acronym that is itself an early easter egg.

    Now would anyone design this timekeeping scheme now? No. This scheme
    is an ancient design, and one that bypasses a restriction or limitation
    in the timekeeping hardware that haven't existed in, well, twenty years
    or so. And all this for VAX hardware that is itself, well, ancient.

    Recent Standalone BACKUP kits will always prompt for the time as these
    kits tend to be of a different year. In earlier times, there was no
    prompt for the time, and there were correspondingly widespread reports
    of the system time being off by a year or so, triggered by the time
    value saved in the SYS.EXE image present in the standalone environment.

    Wacky TOY values are (usually) detected, and these then (also) trigger
    the time prompting during bootstrap.

    The copy of the OpenVMS FAQ located at the HP web site is about two
    revisions back, FWIW. The HoffmanLabs site has a newer edition.





    --
    www.HoffmanLabs.com
    Services for OpenVMS

  9. Re: VAX hardware clock question

    On Sun, 28 Oct 2007 15:01:19 -0700, AEF
    wrote:

    > > TOY clock is a 32 bit counter, i.e. it can count from %X00000000 to
    > > %XFFFFFFFF, ticking every 10 ms. Upon SET TIME it is initialized at
    > > %X10000000, so we have the following (in non-leap years):

    >
    > Why is it initialized to %X10000000?


    To be honest, I have no idea. That value is mentioned in various web
    pages and comp.os.vms past messages too. I think it has something to
    do with the ability to detect failing or failed TOY batteries. Maybe
    someone else on this group will shed some light on the matter.

    Bye,
    G.


+ Reply to Thread