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
