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. 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. _________________________________________________________________ Dave Jousma Assistant Vice President, Mainframe Engineering [email protected] 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Vince Coen Sent: Tuesday, October 27, 2015 7:12 AM To: [email protected] Subject: Re: RE-IPL for the Daylight to Standard time conversion? I would have thought that all these issues would have been easy to be resolved if all sites used UTC time on hardware level with the adjustment for local set up at the software level then it only requires simple job step to adjust if there is not one built in to the O/S. Also and if needed that no job/processes was allowed to run over the time period of time change where such a process might get upset. Let face it as clock change occurs for most of us on a Sunday this should not really be a major problem. I am somewhat surprised that IBM does not have standard procedures / processes / Job in place to handle this including checking the hardware clock against an external source the same that Unix, Linux, Windows does even if it has to go through a inhouse Intranet server for security. On 27/10/15 06:14, Paul Gilmartin wrote: > On Mon, 26 Oct 2015 23:02:41 -0500, Joel C. Ewing wrote: >> Since UNIX and Windows platforms handle DST by just forcing the local >> time discontinuity, if an application has a problem with that, you >> don't have a choice other than tolerating the result or trying to >> find and fix any intolerable problems the discontinuity causes for the >> application. >> I'm sure there are cases on those platforms where a rare "strangeness" >> at time zone changes is just tolerated, since users in those >> environment traditionally seem to expect a higher level of s--- >> happens and some occasional apparent non-determinism.. >> > I'm trying to imagine my UNIX-oriented colleagues' snickering at the > idea of shutting down a system at the DST transition. When they > stopped giggling, I'd expect them to ask, "But which time zone; which > country? All? Northern or Southern Hemisphere? Both?" UNIX systems > run their system clocks on UTC and an input to localtime() is a time > zone chosen by the programmer. It would be absurd to expect an hour's > outage for each of several dozen time zones in the world. z/OS has a > peculiar tunnel vision in its belief that there are only two time > zones. > > Leap seconds are a different issue. z/OS shuts down all applications > during a leap second. Google and Amazon both steer their clocks slow > (less than 0.01 percent) for several hours centered on a leap second. > And the two have chosen different steering durations. > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
