On 2015-10-27, at 05:24, Jousma, David wrote: > IBM does have standard procedures/process etc. It is still up to the local > system administrators to choose to use them. We keep our time sync's via NTP > from the HMC's to the hardware with STP. There are facilities available > today to automatically adjust the time. It is just a hard historical > holdback for many to allow that to happen - including us. > > Short of just changing time, there really is no reason the process couldn’t > be automated to make it hands off. > > Using automation you could > - shutdown the apps that feel they can't tolerate the change > - drain batch (if needed) > - adjust the time > - perform any refresh commands (CICS is one) > - startup any shutdown apps. > Any discussion which mentions "changing" or "adjust" requires a paradigm shift. A proper implementation should have a function that takes as input a system clock value and a time zone and returns the corresponding civil time in that time zone. For given system clock and time zone inputs, that function should give exactly the same value today that it will give a week from today. nothing should need to change or be adjusted next Sunday.
This may have been the objective of STCKCONV and CONVTOD, but they fall far short of it. IBM refuses to document them. I suspect IBM is simply ashamed of their deficiencies. > At this day of age, there is NO REASON why an installation should continue to > run with GMT=LOCAL. GMT must be set to UTC, no if's ands or but's. > Isn't GMT just an obsolete predecessor of UTC? "GMT=LOCAL" is as meaningless as saying "2+2=5" or "one mile is one kilometer." -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
