Dear Colleagues, there is a section on the effects of leap second changes on z/OS dispatchability in the following redbook on page 150.
Server Time Protocol Implementation Guide (Draft) Chapter 2 Operations 2.2 Operations in an STP-only CTN 2.2.6 Time management Leap second considerations http://www.redbooks.ibm.com/redpieces/abstracts/sg247281.html <snip> Operating system and subsystem components use the STCK time format because this is not subject to either Leap Second Offset or time-zone offset changes. Two successive invocations of the Assembler TIME macro in STCK format yield different results, and the second result is later than the first result. Despite the fact that leap seconds are not included in STCK time, the application of positive leap second offset changes can be disruptive and should be done with extreme caution. During the implementation of a positive leap second offset change, z/OS becomes non-dispatchable for the duration of the delta between the current leap second offset and the new leap second offset in order to insert the delta between STCK time and UTC time. The non-dispatchability is required to insert the leap second difference between STCK time and UTC time. In effect, the positive leap second offset delta is subtracted from the current UTC time, which would cause duplicate UTC timestamps if the non-dispatch ability was not in effect for the same interval. Negative leap second offset changes are implemented directly by adding the leap second offset delta to the current UTC time. In this case there is no requirement for z/OS to be made non-dispatchable, as this will not result in duplicate UTC time stamps, and therefore there should be minimal disruption. </snip> Not that I like the thought of the entire OS freezing for one (or even more) seconds just because of a change in the offset between UTC and TAI. So the root of all evil in this case is using some kind of time-of-day timestamps rather than raw clock values, which simply count the ticks since 0001-01-01 00:00:00 (plus providing a programmable field). At least z/OS can handle simply running the hardware clock in sync with TAI and let the software do all the UTC, DST, leap year, leap second and local time interpretation, which is more than what is provided by Unix/POSIX time. kind regards ... Gerald -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Paul Gilmartin Sent: Tuesday, March 17, 2009 10:43 PM To: [email protected] Subject: Re: Leap seconds But positive leap seconds are more likely problematic than negative leap seconds. I disagree still with an IBM employee who stated in these pages a few years ago that there is code in the OS such that should a "negative" leap second ever occur the system will be idled for that second to avoid the hazard of apparently decreasing UTC values. Rather, I suspect that is done routinely at "positive" leap seconds to spare the TIME macro the need to supply UTC values of 23:59:60.hh, and to spare applications the need to deal with them. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
