My two-cents. I've worked in many sites with different takes on this.
Some only IPL twice a year, for the time change. They recognized it wasn't a requirement for the IPL, but continued to schedule it for 'clean-up' purposes. The time change gave them an excuse for the IPL. I've also worked at sites who schedule monthly IPLs. They will schedule the time change to coincide with the IPL, also for 'clean-up' and to implement changes. They stuck to that sehedule so that the user community expects a monthly outage. And then there are the sites that IPL weekly. Once again they recognize it is not always needed but offers a chance for changes to be implemented if needed. They will take advantage of the fall-back to shutdown realtimes for a full hour. One site was very concerned about overlapping timestamps in IDMS impacting forward recovery, even though I never saw a need for an actual forward recovery situation at that site and CA well documented a work-around. Dan -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Charles Mills Sent: Tuesday, October 27, 2015 9:53 AM To: [email protected] Subject: Re: RE-IPL for the Daylight to Standard time conversion? Thanks all. Failed to say that we did ask the service bureau why, and were told "because of the time change. " You all have given me the knowledge necessary to push back for a better answer. Summarizing, there are three possible reasons: 1. The hardware clock is set to local time and it is necessary to stop for an hour to avoid duplicate timestamps. 2. There are one or more applications that use civil time, are difficult to restart without an IPL, and have a potential duplicate or incorrect time problem. 3. Neither of the above, but operations management is in the habit of behaving as though one or both were true. With regard to 1, this is less than a best practice, and should be relatively easy to correct, as UTC is ahead of their local time and no duplicate times eould result. 2 is more difficult. We are all familiar with unmaintainable applications. Further, they are a service bureau and for all I know the application belongs to their largest customer who has said "deal with it or we will find a service bureau that can." With regard to 3, what can I say. Fair enough summary? CharlesSent from a mobile; please excuse the brevity -------- Original message -------- From: Vince Coen <[email protected]> Date: 10/27/2015 5:54 AM (GMT-08:00) To: [email protected] 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
