I can think of a few issues with the clock going backward. Data Base recovery becomes a nightmare. LOGs and SMF post processing see double events. I am sure there is more. The best solution I've seen is to keep the TOD set to GMT and set your local time (zone) accordingly. Most things I've looked at (and it's not exhaustive) store GMT in the DATA and convert it later when your report.
Now someone will quickly point out the error in my logic but I'm just sharing my experience. Regards, Rob Weiss z/SWITA and z/Series I/T Security and Privacy Consultant IBM Software Group Sales IBM Mainframe Discussion List <[email protected]> wrote on 05/11/2006 12:50:16 PM: > McKown, John wrote: > > I guess my question is: Why does IBM and other software vendor depend on > > the TOD clock not changing "drastically" and never, ever, "going > > backwards"? > > Ours is not to reason why. The architecture (PoOps) describes the > behavior of the TOD clock and other facilities. These behaviors were > decided upon a long, long time ago and applications depend on them. You > can no more allow the TOD to go backwards than you can allow a CDS > instruction to not serialize in some cases. That's how it works because > it's documented that way! > > > How would you address this "complaint". Without spending any > > money (gilt, lucre, dinero, ...) > > > > Issue a daily SET TIMEZONE= command to adjust the local time as necessary. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
