On 8 July 2014 14:29, John Gilmore <[email protected]> wrote:
> The z/Architecture TOD clock provides values trhat are analogous to > International Atomic Time, TAI, ones, which are innocent of > leap-second corrections. UTC values do contain these corrections, and > IBM provides facilities for incorporating their then current net > effect in any notional STCKE value (or not). > While it's true that the TOD is ticking steady without knowing about leap seconds, once you use ETR/STP with NTP to keep pace, the TOD produced by STCK will effectively give UTC which, as you point out, includes those leap seconds. When a leap second is inserted in UTC, the TOD (like other NTP linked systems) will slow down during the rest of the night and be on time in the morning. Unless you schedule a change of your own deviation of the UTC at the time the rest of the folks insert that second (and effectively run the TOD on TAI rather than UTC). Or can z/OS update the LPAR TOD offset to make run TAI rather than UTC? It appears the typical non-steered TOD is about 3 ppm slow, so will be off by 2 seconds after a week. I can't imagine those installations being concerned about leap seconds.I would be interested to hear about installations that deliberately wish to run TAI rather than UTC. For sure there will be such requirements, or IBM would not have added the ability in the HMC. Rob
