Before I got here the TODs on the CPCs had always been set to local time, so it might be just a historical quirk at some installations based on the original installation choice many years ago.
I remember when we changed from TOD=LOCAL to TOD=GMT+offset about 10+ years ago. Painful, but the results are worth it. In our case because we're ahead of GMT (Aussies) it was a bit of a trick to get the couple datasets right but no drama after testing (there was a recent discussion on couple datasets and time changes). Now it's just adding or taking away the DST offset on whatever is the sysplex's time source, STP or Timers depending on the plex. Note that we still have to bounce some CICS regions as their apps can't tolerate the backwards move, but going forwards is no outage and backwards is really no drama except for wayward apps like ours who use local time instead of GMT. cheers Peter On Fri, 13 Mar 2009 01:49:00 -0400, Robert A. Rosenberg <hal9...@panix.com> wrote: >At 14:29 -0700 on 03/12/2009, Gibney, Dave wrote about Re: Time Change (Sync): > >> Clocks are a different story. Twice a year I have to take the sh*t >>about how hard or expensive it is to have our z9 in sync with the rest >>of the world. > >Why is your CPU clock not set to GMT/UT? That would insure that there >is no need to reset the clock - Just update the local time offset >twice a year. So long as time stamps are in GMT, the DST/ST switches >should not affect anything important. > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO >Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
