> If you have an external time source (or the hardware STP feature), this is probably automatic.
So the time source "knows" about the local time change at 2 am and tells the Z system? I guess I see that. ETRZONE YES "Specifies that the system is to use the Sysplex Timer to set the time zone constant." > 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. I am the lead developer of such a system. Yes, we need "no intervention" but I am trying to make sure we handle the local time change in the best way possible. It's a tough thing to test "in real life" because the time change only happens twice a year. It does not happen in these subsystems by magic; it happens because someone coded the logic correctly. That's what I need to make sure we do. FWIW, we have no "logical" dependency on local time (e.g. like database timestamps that control recovery logic) but (a.) some of our inputs are in local time -- the SMF standard timestamp for a start -- and (b.) some of our outputs either must be or may customer-configured to be in local time. Do you know the answer to my question 2? Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Allan Staller Sent: Thursday, February 22, 2018 5:49 AM To: [email protected] Subject: 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:[email protected]] On Behalf Of Charles Mills Sent: Wednesday, February 21, 2018 6:46 PM To: [email protected] 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? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
