RE: MN 4.4, XNTP and Time Change - VMS

This is a discussion on RE: MN 4.4, XNTP and Time Change - VMS ; "Fairfield, Ken :CO IR" wrote on 10/26/2007 05:29:56 PM: > Norm Raphael wrote: > > > I always run the command procedure for time setup > > sys$manager:utc$time_setup.com > > interactively to fix up the TDF. > > In my ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: RE: MN 4.4, XNTP and Time Change

  1. RE: MN 4.4, XNTP and Time Change

    "Fairfield, Ken :CO IR" wrote on 10/26/2007 05:29:56
    PM:

    > Norm Raphael wrote:
    >
    > > I always run the command procedure for time setup
    > > sys$manager:utc$time_setup.com
    > > interactively to fix up the TDF.

    >
    > In my new job, I "discovered" that you can execute UTC$TIME_SETUP with
    > parameters and avoid having to answer prompts. :-) See below...
    >
    > > It should be submittable, but I question the comments.

    >
    > Yes.
    >
    > > The interactive prompt for TDF seems to be in (plus/minus)hh:mm
    > > while the comment says the parameters for TDF and offset are in
    > > minutes (and doesn't explain what the "offset" is, by the way).
    > > The TDF is usually in (plus/minus)hh:mm and the offset is
    > > usually in (plus/minus)seconds.
    > > What would be the correct values to go back to EST?

    >
    > I think you want the following for EST (TDF is -5 hours = -300 minutes,
    > right?):
    >
    > @Sys$Manager:Utc$Time_Setup SYS$COMMON: TDF -300 0
    >


    This looks exactly right, thanks.

    Now if one were to submit it, would that be at 2:00:30 am?
    One would want it to run after the second 2:00am, yes or it would
    run too early?
    Or would one submit something to run at the first
    1:59:00 to submit it to run at the second 1:01 am (Oops, that would
    release, not hold)? [I guess that'w why they made it a sysgen
    parameter....]

    > The last parameter (P4 = 0) says *don't* change the system time. If
    > you *do* want to change the system time, set P4 to the number of minutes
    > you want to change, so:
    >
    > @Sys$Manager:Utc$Time_Setup SYS$COMMON: TDF -300 -60
    >
    > [snip]
    >
    > > I am using Multinet XNTP which does not do the TDF.

    >
    > See Richard Whalen's remarks about XNTP and time changes. I take his
    > answer to be, shut down XNTP during the time change.
    >
    > OTOH, see also Carl Bennett's response that he "just leaves XNTP

    running",
    > albeit with AUTO_DLIGHT_SAV set to 1... YMMV
    >
    > ---
    > On a related but separate subject, it seems that when doing

    UTC$TIME_SETUP
    > on a system where the logical SYS$TIMEZONE_RULE is define, only the only
    > logical changed is SYS$TIMEZONE_DIFFERENTIAL. In particular, neither
    > SYS$TIMEZONE_NAME nor SYS$TIMEZONE_DAYLIGHT_SAVING are changed. I've

    just
    > spend tracing through the system

    startup
    > procedures, etc., to figure out where/when those get defined on system
    > boot.
    >
    > Through various circuitous paths, during VMS$BASEENVIRON-050-VMS, will
    > execute Sys$Startup:TDF$UTC_Startup.Com (if present). That file invokes
    > Sys$System:TDF$Set_Timezone.Exe with appropriate parameters. But the
    > command file takes an early exit if Sys$Timezone_Rule is defined.
    >
    > So I experimented on a test system. If I Deassign/System/Exec
    > SYS$TIMEZONE_RULE
    > logical and then execute Sys$Startup:TDF$UTC_Startup.Com, *all* the
    > Sys$Timezone*
    > logicals get updated, as well as the system TDF in EXE$GQ_TDF. :-)
    >
    > I don't know what would happen if you were to do this at "02:01 PDT",

    one
    > minute past the time change, but it looks like an interesting

    alternative.
    > OTOH, setting AUTO_DLIGHT_SAV to 1 is probably easier and more robust

    (but
    > requires a system reboot since it's not dynamic).
    >
    > Cheers, Ken
    > --
    > Ken Fairfield
    > System Administrator, Information Resources
    > Legacy Health System
    > 1919 NW LoveJoy, Portland, OR 97209
    >
    > Who: MyFirstInitialMyFullLastName
    > Where: lhs -dot- org
    >
    >
    >
    > IMPORTANT NOTICE: This communication, including any attachment,

    contains
    > information that may be confidential or privileged, and is intended

    solely
    > for the entity or individual to whom it is addressed. If you are not

    the
    > intended recipient, you should contact the sender and delete the

    message.
    > Any unauthorized disclosure, copying, or distribution of this message is
    > strictly prohibited. Nothing in this email, including any attachment,

    is
    > intended to be a legally binding signature.



  2. Re: MN 4.4, XNTP and Time Change

    norm.raphael@metso.com wrote:
    > "Fairfield, Ken :CO IR" wrote on 10/26/2007 05:29:56
    > PM:
    >
    >> Norm Raphael wrote:
    >>

    [...]
    >>> What would be the correct values to go back to EST?

    >> I think you want the following for EST (TDF is -5 hours = -300 minutes,
    >> right?):
    >>
    >> @Sys$Manager:Utc$Time_Setup SYS$COMMON: TDF -300 0
    >>

    >
    > This looks exactly right, thanks.
    >
    > Now if one were to submit it, would that be at 2:00:30 am?
    > One would want it to run after the second 2:00am, yes or it would
    > run too early?
    > Or would one submit something to run at the first
    > 1:59:00 to submit it to run at the second 1:01 am (Oops, that would
    > release, not hold)? [I guess that'w why they made it a sysgen
    > parameter....]


    ....Sorry to be so late in following up to this...

    To answer your question, it depends mostly on whether you have
    any applications that care about UTC, and therefore the TDF,
    being correct precisely at the time change. My personal take
    is that having the TDF be changed in precise synchronization
    with the time change is not particularly important. But if
    that's what you want, you can tell UTC$TIME_SETUP to do both
    the time change and the TDF change, right? (I don't recall how
    you said you change the time, but it sounded separate from
    UTC$TIME_SETUP.)

    I suppose you could change the TDF at 01:59:59 EDT, then have
    the clock jump back at 02:00:00 EDT to be 01:00:00 EST and
    you'd be fine. You can't submit a job to run at 02:00:01 EDT,
    but change the clock back an hour at 02:00:00 and expect that
    job to release in the next second: it will, of course wait
    until 02:00:01 EST (you having changed the system clock). And
    neither can you submit to run at 01:00:01 "EST" because that
    time will have come and gone while you were still in EDT.

    Another thing you could do, but I think it's going to way too
    much work, would be to submite a job to release at 01:59:59,
    bnut then have it $ Wait 00:00:02 (or however many seconds you
    want) so that it changes the TDF one second past the time change.
    But like I said...

    ----
    I re-read your prevoius post where you show the output of
    @sys$manager:utc$time_setup show. That output implies you
    have AUTO_DLIGHT_SAV set to 1. It also shows that most of
    the SYS$TIMEZONE_* logicals are *not* defined.

    It seems to me the easiest/most reliable thing for you to do
    would be to go through UTC$TIME_SETUP once, with prompting, and
    set up your timezone correctly, once and for all. Then with
    AUTO_DLIGHT_SAV already set to 1, let VMS change everything for
    you automatically: the time, the TDF, the logical names,
    everything. The only thing you need to do (if I'e understood
    your configuration) is to shutdown XNTP before the time change,
    let the "twilight zone" hour pass, and then restart XNTP.
    (That's certainly my plan next time, or if I ever, get to reboot
    the cluster to change AUTO_DLIGHT_SAV...)

    -Ken
    --
    Ken & Ann Fairfield
    What: Ken dot And dot Ann
    Where: Gmail dot Com

+ Reply to Thread