Re: Another DST issue - VMS

This is a discussion on Re: Another DST issue - VMS ; moroney@world.std.spaamtrap.com (Michael Moroney) wrote on 10/30/2008 11:56:00 AM: > We have an application that until this spring was running on a VAX running > V7.3. It has been ported to an Itanium running V8.3. The application is > (very) old ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Re: Another DST issue

  1. Re: Another DST issue

    moroney@world.std.spaamtrap.com (Michael Moroney) wrote on 10/30/2008
    11:56:00 AM:

    > We have an application that until this spring was running on a VAX

    running
    > V7.3. It has been ported to an Itanium running V8.3. The application

    is
    > (very) old and does not handle DST time changes. What they've done in

    the
    > past for DST time changes is wait until a quiet time, stop the
    > application, manually set the time and restart the application.
    >
    > However, the new system has been set up using NTP and with SYSGEN

    parameter
    > AUTO_DLIGHT_SAV set to 1. This means that VMS will automatically set

    the
    > clock back this Sunday for us. However, this parameter is _not_

    dynamic.
    > Is there a way to change things so as to not set the time back, short of
    > rebooting with AUTO_DLIGHT_SAV 0? (I've already set it back to 0 in the
    > CURRENT parameters so this won't bite us again this spring (assuming

    there
    > is a reboot before then, not a good assumption with VMS!)
    >
    > Stopping NTP is simple enough, it's the auto time change that's the

    issue.
    > We can't predict when there will be a quiet time.

    Someone should correct me if I'm wrong and provide details if I'm not, but
    if
    you remove the TimeZoneRule from the logical name tables the reset should
    fail.

  2. Re: Another DST issue

    On Oct 30, 1:35*pm, norm.raph...@metso.com wrote:
    > moro...@world.std.spaamtrap.com (Michael Moroney) wrote on 10/30/2008
    > 11:56:00 AM:
    >
    >
    >
    >
    >
    > > We have an application that until this spring was running on a VAX

    > running
    > > V7.3. *It has been ported to an Itanium running V8.3. *The application

    > is
    > > (very) old and does not handle DST time changes. *What they've done in

    > the
    > > past for DST time changes is wait until a quiet time, stop the
    > > application, manually set the time and restart the application.

    >
    > > However, the new system has been set up using NTP and with SYSGEN

    > parameter
    > > AUTO_DLIGHT_SAV set to 1. *This means that VMS will automatically set

    > the
    > > clock back this Sunday for us. *However, this parameter is _not_

    > dynamic.
    > > Is there a way to change things so as to not set the time back, short of
    > > rebooting with AUTO_DLIGHT_SAV 0? *(I've already set it back to 0 in the
    > > CURRENT parameters so this won't bite us again this spring (assuming

    > there
    > > is a reboot before then, not a good assumption with VMS!)

    >
    > > Stopping NTP is simple enough, it's the auto time change that's the

    > issue.
    > > We can't predict when there will be a quiet time.

    >
    > Someone should correct me if I'm wrong and provide details if I'm not, but
    > if
    > you remove the TimeZoneRule from the logical name tables the reset should
    > fail.- Hide quoted text -
    >
    > - Show quoted text -


    Also, you might be able to modify the timezonerule logical or
    configure to a different time zone so that the NOV 2 is a NOOP.


  3. Re: Another DST issue

    norm.raphael@metso.com writes:

    >Someone should correct me if I'm wrong and provide details if I'm not, but
    >if
    >you remove the TimeZoneRule from the logical name tables the reset should
    >fail.


    I think I figured out a way to sort of do the same thing. Use
    sys$manager:UTC$TIME_SETUP.COM and set the timezone to EST. The time
    change becomes a no-op. They manually set the time back an hour when
    convenient. So far testing shows this is what will happen.

  4. Re: Another DST issue

    tadamsmar writes:

    >Also, you might be able to modify the timezonerule logical or
    >configure to a different time zone so that the NOV 2 is a NOOP.


    Great minds think alike.

+ Reply to Thread