The 24*7*365 companies have solved it. Versus the 24*7*364.96 companies that haven't.
On Tue, Oct 27, 2015 at 10:14 AM, Ted MacNEIL <eamacn...@yahoo.ca> wrote: > How about internationally? > Not all companies close on weekends! > > - > -teD > - > Original Message > From: Vince Coen > Sent: Tuesday, October 27, 2015 08:54 > To: IBM-MAIN@LISTSERV.UA.EDU > 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: IBM-MAIN@LISTSERV.UA.EDU >> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
