The most important question is whether your LPAR(s) are running with true 
GMT/UTC. It was once customary for shops to set both GMT and Local time to a 
nearby wall clock and specify zero Local offset. Over time most shops have 
hopped on to the straight and narrow path by defining GMT as UTC with a Local 
offset that either varies (or does not) by season. If you using a true offset 
value, you can use 'some timer facility' to adjust the offset twice a year. For 
us that was once the external sysplex timer (9037). Now it's built-in STP 
(Server Time Protocol) that performs the time change operation--automatically 
if desired. An IPL is not necessary for z/OS.

Otherwise you can issue the SET CLOCK command. However, that changes only the 
running system. Any desired change to 'parm' fields would have to be done 
manually. Again, an IPL is not necessary for z/OS.

As others have said, most modern software like CICS and DB2 logs in UTC, so 
changes to Local time don't matter except to Bioware. The one-hour overlap when 
'falling back' is not a problem except for people reading syslog or operlog, 
where duplicate time stamps will appear. I'm quite sure that a multiplex 
requires some kind of hardware timer because XCF cannot handle differing time 
stamps among members.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Allan Staller
Sent: Thursday, February 22, 2018 5:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Two summer time change questions

It depends.
If you have an external time source (or the hardware STP feature), this is 
probably automatic. Check your CLOCKxx members in SYS1.PARMLIB.

The other alternative is to manually issue a SET TZ  command at the appropriate 
time (either by automation or human).

For the record, all of the major subsystems (DB2, IMS, CICS, z/OS, Websphere, 
BMC..., Compuware... CA,,, ) I am aware of need no intervention to handle the 
time change.
The only remaining hurdle in most shops regarding time change is application 
logic.

For the Spring time change there is usually no issue, for the Fall time change, 
many shops go idle for 1 hour to prevent the possibility of duplicate time 
stamps (based on local time).

HTH,

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Wednesday, February 21, 2018 6:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Two summer time change questions

First though, apologies for asking what perhaps has been covered before -- 
perhaps even asked by me. I am having no luck searching the archives. I search 
on CVTTZ and get no hits even though I have IBM-MAIN messages in my own Outlook 
that contain CVTTZ.

1. Humor a guy with almost no operations experience with the world's most 
newbie operations question. If you are a shop in North America, how will you 
"convert" your z/OS instances to summer time next month? Do you or does your 
console automation software have to enter a SET command, or does it happen 
automagically internally to z/OS on some pre-configured schedule? (I remember I 
had a P/390 back in the day and VM had an internal table that did the time 
change automagically but I recall I had to re-IPL OS/390 to pick up the change.)

2. When the above happens, will CVTTZ and CVTLDTO get updated on the fly? If I 
inspected them one second would I see an offset of, e.g., 8 hours (in TOD or 
"TOD-high word" format as appropriate) and if I inspected them a second later I 
would see 7 hours?

Charles


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to