On 10/26/2015 04:28 PM, Charles Mills wrote: > I'm a developer, not an operations guy. My boss has asked me why a > datacenter we use would need to IPL for the daylight to standard time > transition. He asks if the box does not use UTC, and I said that yes, the > hardware clock is generally set to UTC but that perhaps the LPAR time zone > change required an IPL. > > Can anyone enlighten me? Why might our datacenter need or want to IPL for > the Daylight to Standard time conversion? > > Thanks, > > Charles > > This is primarily a "political" and resource allocation issue, not a z/OS issue as z/OS itself can tolerate the jump without an IPL, provided it's done like it's supposed to be by just changing the local offset from the hardware TOD clock, either automatically or manually.
If important, most-loved applications are known to record and use local time in a number of contexts and no one is willing to expend resources to research whether they will produce unacceptable results across a discontinuity in local time; nor willing to just "try" the jump see if anything breaks and if so fix it, then the least risky and most politically acceptable recourse may be to shut down all regions supporting that application. When that means shutting down the most significant parts of a z/OS system, sometimes the least disruptive way to do that is to just shut down the entire z/OS system and re-IPL -- which also provides a window to install any pending system changes that might be easiest or safest to install across an IPL. One reason why there may be low political motivation to seek to eliminate a time change IPL is that when the primary user community has become long accustomed to expect and accept a service disruption at such times, this can provides a system or hardware maintenance window subject to minimal end-user objection. Obviously, any new application that manipulates or stores local times should do so in a way that that somehow preserves time zone offset as an integral part of local time and takes care to also use that offset in any context when local time is used to order events by time or to compute duration between events; and any interfaces used by applications to obtain those local time values should be designed to give consistent time and time offset values across a local-time discontinuity. To verify after the fact that any large existing application that was not designed with those rules in place can tolerate a local time discontinuity may not be a trivial exercise. 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.. -- Joel C. Ewing, Bentonville, AR jcew...@acm.org ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
