RE: MN 4.4, XNTP and Time Change - VMS

This is a discussion on RE: MN 4.4, XNTP and Time Change - VMS ; 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 ...

+ 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

    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

    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

    Thanks =)

    -----Original Message-----
    From: Fairfield, Ken :CO IR [mailto:KFairfield@LHS.ORG.]
    Sent: Friday, October 26, 2007 5:30 PM
    To: info-multinet@process.com.
    Cc: Fairfield, Ken :CO IR
    Subject: RE: MN 4.4, XNTP and Time Change

    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

    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.

+ Reply to Thread