Another DST issue - VMS

This is a discussion on Another DST issue - VMS ; 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 ...

+ Reply to Thread
Results 1 to 15 of 15

Thread: Another DST issue

  1. Another DST issue

    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.

  2. Re: Another DST issue

    Michael Moroney wrote:
    > 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.


    Could you provide some background on why the application does not handle
    the time change ?

    When I worked with the ST400 (SWIFT) application, they would disconnect
    from the network between 01:00EDT and 02:00EST to ensure no message came
    in or out during a period where time stamps could be duplicated. But the
    application itself had no problems with it.

    So having some background on why your app can't handle the time change
    might help with finding a solution.

    There was some application some time ago which tweaked the clock speed
    and allowed the system to take 2 hours to go from 01:00 to 02:00. This
    way, no time stamp would be duplicated and no message would be stamped
    with a time that was before the previous transaction.

  3. Re: Another DST issue

    JF Mezei writes:

    >Michael Moroney wrote:
    >> 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.


    >Could you provide some background on why the application does not handle
    > the time change ?


    >So having some background on why your app can't handle the time change
    >might help with finding a solution.


    It's very old, has no concept of time zones (or needs to), it uses time
    as returned by SYS$GETTIM(). It implicitly assumes time is monotonically
    increasing, and having events end before they ever begin really throws a
    monkey wrench into things.

    Stopping and immediately restarting the application is what they've been
    doing so far.

    >When I worked with the ST400 (SWIFT) application, they would disconnect
    >from the network between 01:00EDT and 02:00EST to ensure no message came
    >in or out during a period where time stamps could be duplicated. But the
    >application itself had no problems with it.


    Being down for an hour isn't acceptible.

    >There was some application some time ago which tweaked the clock speed
    >and allowed the system to take 2 hours to go from 01:00 to 02:00. This
    >way, no time stamp would be duplicated and no message would be stamped
    >with a time that was before the previous transaction.


    To them, something timestamped 4:10 AM (EDT) which really happened at
    3:10 AM (EST) is acceptible as it is easily traceable to a specific time.
    Something with a time 3:56 AM which really happened at 3:10 AM (EST) isn't.

  4. Re: Another DST issue

    Michael Moroney wrote:

    > as returned by SYS$GETTIM(). It implicitly assumes time is monotonically
    > increasing, and having events end before they ever begin really throws a
    > monkey wrench into things.


    How long do "transactions" last ? Milliseconds, seconds, minutes ? tens
    of minutes ? Hours ?

    If transactions last just a few seconds, then you could stop them coming
    in say 10 seconds before the time change at 02:00 EDT. All transactions
    would have time to complete before the time change. Once time has
    changed, you can then let new transactions come in.People would just
    think there was a temporary glitch lasting a couple of seconds.

  5. Re: Another DST issue

    In article , Michael Moroney wrote:
    >JF Mezei writes:
    >
    >>Michael Moroney wrote:
    >>> 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.

    >
    >>Could you provide some background on why the application does not handle
    >> the time change ?

    >
    >>So having some background on why your app can't handle the time change
    >>might help with finding a solution.

    >
    >It's very old, has no concept of time zones (or needs to), it uses time
    >as returned by SYS$GETTIM(). It implicitly assumes time is monotonically
    >increasing, and having events end before they ever begin really throws a
    >monkey wrench into things.

    [...]
    If you can take advantage of using UTC on the system, you might avoid these
    problems. Hoff has written a nice article:



  6. Re: Another DST issue

    JF Mezei writes:

    >Michael Moroney wrote:


    >> as returned by SYS$GETTIM(). It implicitly assumes time is monotonically
    >> increasing, and having events end before they ever begin really throws a
    >> monkey wrench into things.


    >How long do "transactions" last ? Milliseconds, seconds, minutes ? tens
    >of minutes ? Hours ?


    Tens of minutes to many hours, though some can be closed in seconds.

    But this is all barking up the wrong tree. What happens when the time
    goes backwards is well understood to be bad, and there is a deadline of
    2:00 AM, NOV 2 2008 to get the setback to happen in a controlled manner.
    Others have suggested running off GMT or something and I suggested that as
    well once but they have to keep local time.



  7. Re: Another DST issue

    Michael Moroney wrote:

    > Others have suggested running off GMT or something and I suggested that as
    > well once but they have to keep local time.


    Moving to GMT may advance the time (I assume you are in north america).
    But eventually you want to switch the time back and you will get
    problems at that time.


    You might consider changing to a time zone which does not have daylights
    savings time. For instance, Saktaschewan Canada doesn't change time. (it
    is central time).

  8. Re: Another DST issue

    VAXman- @SendSpamHere.ORG wrote:
    > Feign the local time by intercepting the system services which provide
    > the time in human readable format so that they appear to be the current
    > time zone but the underlying time is that of the system time quadword
    > which remains modified. I have software which can do this very thing
    > on all three supported OpenVMS platforms -- and correctly too. There
    > were a number of products which did this and were advertised during the
    > run-up to Y2K for testing purposes. I tested one -- I believe it was
    > called TimeWarp -- and which Compaq has been promoting. It didn't even
    > come close to getting it right so be very weary of the solution of you
    > should decide to go this route.
    >


    A former employer used one, I think it was called DateSim. It was sold
    to us through Software Partners (I think), but it was written by Wayne
    Sewell (hope I got the spelling right). That worked pretty well. We did
    run into one bug. However, I don't recall what it was. It was fixed, but
    we ended up splitting the customers on different timezones onto different
    machines.

    Tim.

  9. Re: Another DST issue

    In article , moroney@world.std.spaamtrap.com (Michael Moroney) writes:
    >JF Mezei writes:
    >
    >>Michael Moroney wrote:

    >
    >>> as returned by SYS$GETTIM(). It implicitly assumes time is monotonically
    >>> increasing, and having events end before they ever begin really throws a
    >>> monkey wrench into things.

    >
    >>How long do "transactions" last ? Milliseconds, seconds, minutes ? tens
    >>of minutes ? Hours ?

    >
    >Tens of minutes to many hours, though some can be closed in seconds.
    >
    >But this is all barking up the wrong tree. What happens when the time
    >goes backwards is well understood to be bad, and there is a deadline of
    >2:00 AM, NOV 2 2008 to get the setback to happen in a controlled manner.
    >Others have suggested running off GMT or something and I suggested that as
    >well once but they have to keep local time.


    Feign the local time by intercepting the system services which provide
    the time in human readable format so that they appear to be the current
    time zone but the underlying time is that of the system time quadword
    which remains modified. I have software which can do this very thing
    on all three supported OpenVMS platforms -- and correctly too. There
    were a number of products which did this and were advertised during the
    run-up to Y2K for testing purposes. I tested one -- I believe it was
    called TimeWarp -- and which Compaq has been promoting. It didn't even
    come close to getting it right so be very weary of the solution of you
    should decide to go this route.

    --
    VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

    .... pejorative statements of opinion are entitled to constitutional protection
    no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

    Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside
    of usenet _must_ include its contents in its entirety including this copyright
    notice, disclaimer and quotations.

  10. Re: Another DST issue

    In article <490AF7B5.6090704@bigpond.com>, "Tim E. Sneddon" writes:
    >VAXman- @SendSpamHere.ORG wrote:
    >> Feign the local time by intercepting the system services which provide
    >> the time in human readable format so that they appear to be the current
    >> time zone but the underlying time is that of the system time quadword
    >> which remains modified. I have software which can do this very thing
    >> on all three supported OpenVMS platforms -- and correctly too. There
    >> were a number of products which did this and were advertised during the
    >> run-up to Y2K for testing purposes. I tested one -- I believe it was
    >> called TimeWarp -- and which Compaq has been promoting. It didn't even
    >> come close to getting it right so be very weary of the solution of you
    >> should decide to go this route.
    >>

    >
    >A former employer used one, I think it was called DateSim. It was sold
    >to us through Software Partners (I think), but it was written by Wayne
    >Sewell (hope I got the spelling right). That worked pretty well. We did
    >run into one bug. However, I don't recall what it was. It was fixed, but
    >we ended up splitting the customers on different timezones onto different
    >machines.


    I remember speaking to Wayne about that. It's no been ported to IA64
    AFAIK and, if it has been, I'd like to know how.

    --
    VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

    .... pejorative statements of opinion are entitled to constitutional protection
    no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

    Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside
    of usenet _must_ include its contents in its entirety including this copyright
    notice, disclaimer and quotations.

  11. Re: Another DST issue

    VAXman- @SendSpamHere.ORG wrote:
    > In article <490AF7B5.6090704@bigpond.com>, "Tim E. Sneddon" writes:
    >> VAXman- @SendSpamHere.ORG wrote:
    >>> Feign the local time by intercepting the system services which provide
    >>> the time in human readable format so that they appear to be the current
    >>> time zone but the underlying time is that of the system time quadword
    >>> which remains modified. I have software which can do this very thing
    >>> on all three supported OpenVMS platforms -- and correctly too. There
    >>> were a number of products which did this and were advertised during the
    >>> run-up to Y2K for testing purposes. I tested one -- I believe it was
    >>> called TimeWarp -- and which Compaq has been promoting. It didn't even
    >>> come close to getting it right so be very weary of the solution of you
    >>> should decide to go this route.
    >>>

    >> A former employer used one, I think it was called DateSim. It was sold
    >> to us through Software Partners (I think), but it was written by Wayne
    >> Sewell (hope I got the spelling right). That worked pretty well. We did
    >> run into one bug. However, I don't recall what it was. It was fixed, but
    >> we ended up splitting the customers on different timezones onto different
    >> machines.

    >
    > I remember speaking to Wayne about that. It's no been ported to IA64
    > AFAIK and, if it has been, I'd like to know how.
    >


    We ran it on Alpha. My only involvement with it was to add support for
    it to a timestamp conversion routine I wrote.

    Tim.

  12. Re: Another DST issue

    On Oct 30, 10:57*pm, moro...@world.std.spaamtrap.com (Michael Moroney)
    wrote:
    > JF Mezei writes:
    > >Michael Moroney wrote:
    > >> as returned by SYS$GETTIM(). *It implicitly assumes time is monotonically
    > >> increasing, and having events end before they ever begin really throwsa
    > >> monkey wrench into things.

    > >How long do "transactions" last ? Milliseconds, seconds, minutes ? tens
    > >of minutes ? Hours ?

    >
    > Tens of minutes to many hours, though some can be closed in seconds.
    >
    > But this is all barking up the wrong tree. *What happens when the time
    > goes backwards is well understood to be bad, and there is a deadline of
    > 2:00 AM, NOV 2 2008 to get the setback to happen in a controlled manner. *
    > Others have suggested running off GMT or something and I suggested that as
    > well once but they have to keep local time.


    Reminds me of the system I developed in the late 1980s. I use Harlan
    Mills development approach and it was very reliable compared with
    other systems my employer had developed.

    We brought it up after the acceptance test and it ran for almost a
    year with a reboot or significant problem. The fall time change
    came. An "audit" mailbox message, a message designed to ensure that
    mailbox message processing was working, arrived before it was sent -
    crash!

  13. Re: Another DST issue

    On Oct 31, 10:07*am, tadamsmar wrote:
    > On Oct 30, 10:57*pm, moro...@world.std.spaamtrap.com (Michael Moroney)
    > wrote:
    >
    > > JF Mezei writes:
    > > >Michael Moroney wrote:
    > > >> as returned by SYS$GETTIM(). *It implicitly assumes time is monotonically
    > > >> increasing, and having events end before they ever begin really throws a
    > > >> monkey wrench into things.
    > > >How long do "transactions" last ? Milliseconds, seconds, minutes ? tens
    > > >of minutes ? Hours ?

    >
    > > Tens of minutes to many hours, though some can be closed in seconds.

    >
    > > But this is all barking up the wrong tree. *What happens when the time
    > > goes backwards is well understood to be bad, and there is a deadline of
    > > 2:00 AM, NOV 2 2008 to get the setback to happen in a controlled manner.. *
    > > Others have suggested running off GMT or something and I suggested thatas
    > > well once but they have to keep local time.

    >
    > Reminds me of the system I developed in the late 1980s. *I use Harlan
    > Mills development approach and it was very reliable compared with
    > other systems my employer had developed.
    >
    > We brought it up after the acceptance test and it ran for almost a
    > year with a reboot or significant problem. * The fall time change
    > came. *An "audit" mailbox message, a message designed to ensure that
    > mailbox message processing was working, arrived before it was sent -
    > crash!


    After this, I did some research on how time going backwards is handled
    in general.

    Trains just stop for a hour and resume schedule in the fall, they play
    catchup in the spring.

    GMT never goes backward as far as I know, it just slows down or speeds
    up as required.

    Big Ben has a stack of pennys on its pendulum, pennys are removed or
    added to get it back to the correct time as needed.

  14. Re: Another DST issue

    On Oct 30, 7:01*pm, B...@rabbit.turquoisewitch.com (Brad Hamilton)
    wrote:
    > In article , Michael Moroney wrote:

    [...snip...]
    >
    > [...]
    > If you can take advantage of using UTC on the system, you might avoid these
    > problems. *Hoff has written a nice article:
    >
    > http://64.223.189.234/node/1111
    >

    This is great advice if it can be implemented on your VMS system. And
    if you think about it, it makes no senses for computers to be changing
    their internal clocks twice a year. In an ideal world all the
    computers whould be synchronized to a common world clock then humans
    would see (if desired) time displayed based upon local user rules. One
    user might want to see EASTERN while another might want to see
    PACIFIC. Files created by each user would be stamped with the machine
    time but each user would see the file time-stamps in the timezone of
    their choice.
    BTW, this is how UNIX systems do it now. The machine timezone is
    defined in /etc/default/init (a.k.a. /etc/TIMEZONE) while the user
    timezone is defined by environment variable TZ.


    Neil Rieck
    Kitchener/Waterloo/Cambridge,
    Ontario, Canada.
    http://www3.sympatico.ca/n.rieck/

  15. Re: Another DST issue

    Neil Rieck writes:

    > This is great advice if it can be implemented on your VMS system. And
    > if you think about it, it makes no senses for computers to be changing
    > their internal clocks twice a year. In an ideal world all the
    > computers whould be synchronized to a common world clock then humans
    > would see (if desired) time displayed based upon local user rules. One
    > user might want to see EASTERN while another might want to see
    > PACIFIC. Files created by each user would be stamped with the machine
    > time but each user would see the file time-stamps in the timezone of
    > their choice.
    > BTW, this is how UNIX systems do it now. The machine timezone is
    > defined in /etc/default/init (a.k.a. /etc/TIMEZONE) while the user
    > timezone is defined by environment variable TZ.


    This is also how TENEX (of an age with UNIX) and its DEC descendant TOPS-20
    do it, although unlike UNIX, which chose 1 January 1970 as the beginning of
    time, they chose a timebase prior to any electronic filesystem, midnight GMT on
    November 17, 1858 (the choice of which is based on Julian days and irrelevant
    to this argument).

    Modern Unices have retrofitted to 1 January 1900, but not in time to save a lot
    of grief.

    --
    Rich Alderson "You get what anybody gets. You get a lifetime."
    news@alderson.users.panix.com --Death, of the Endless

+ Reply to Thread