Never said close but workload is usually a lot lower - excluding bank
system running ATM's etc.
In which case you have to work with other strategies and that depends on
what/when etc.
However all that it is pointed out to ensure that system uses UTC time
and that ALL logging for all and that means both system and application
s/w uses it and just adjusts if local time is really required.
In the various shops / sites I have worked in and that includes a lot
when working as a freelance / contractor most if not all used UTC and
yes in the UK we have summer time which is +1 so software has to deal
with that.
Should point out that even bank system running ATM's have procedures in
place for maintenance of any kind that needs to occur even if the have
secondary system in use as parallel processing & backup.
Heck what banks only use one mainframe these days and here I will
exclude Barclay's RBS etc, that seem to do updates over a w/e and manage
to break the system stopping customers getting their cash.
Here I just blame very poor system testing - but I would as a Test
Manager (among other roles). Absolutely no excuse of it and banks can
afford to have back up systems run in parallel along with a m/f used for
testing and development.
Sorry my age is showing ...
.On 27/10/15 15:14, Ted MacNEIL wrote:
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
