How about internationally? Not all companies close on weekends! - -teD - Original Message From: Vince Coen Sent: Tuesday, October 27, 2015 08:54 To: [email protected] Reply To: IBM Mainframe Discussion List Subject: Re: RE-IPL for the Daylight to Standard time conversion?
Sunday is the *day *that clocks move forwards or back an hour or two. e.g., 02:00 etc. Hardly a heavy work load period unless it is a system upgrade day ! On 27/10/15 11:35, Ted MacNEIL wrote: > What's so special about Sunday? I used to work for an international bank. > Sunday. Was no excuse for an outage! > > - > -teD > - > Original Message > From: Vince Coen > Sent: Tuesday, October 27, 2015 07:11 > To: [email protected] > Reply To: IBM Mainframe Discussion List > 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
