My idea for doing the fall back would be change the fall back time to 0100. Leap forward from 005959 to 020000, no problem. But for fall back, 235959 continues to 240000 to 245959 then the next day at 000000, resulting in no overlapping times.
On Mon, Sep 21, 2020 at 6:13 PM Mark Jacobs <[email protected]> wrote: > > We had the time steering function using sysplex timers. I believe that the > maximum time that could be steered was one minute, which took days/weeks to > accomplish. If you needed more than a minute, you had to start the process > again. STP raised the limit that could be set, but didn't speed it up any. > > Mark Jacobs > > Sent from ProtonMail, Swiss-based encrypted email. > > GPG Public Key - > https://api.protonmail.ch/pks/lookup?op=get&[email protected] > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Monday, September 21, 2020 7:00 PM, Paul Gilmartin > <[email protected]> wrote: > > > On Tue, 22 Sep 2020 07:35:44 +1000, Matthew Donald wrote: > > > > > A few years ago (z14 announcement??), IBM announced a new PR/SM feature > > > which would decrement the TOD clock 1 second at a time, while > > > simultaneously incrementing the timezone offset. Can anyone shine any > > > light on this feature? I've searched through the HMC manuals without any > > > luck - a pointer to documentation would be greatly appreciated. > > > > But that leaves a hazard for a job that fetches CVTLDTO before the STCK(E); > > less so for the job that does the STCK(E) first. But it's possible to steer > > the clock (but only by a couple seconds a day). I assume the hardware > > guarantees uniqueness of STCK, and incrementing CVTLDTO introduces > > no hazard. > > > > I believe the hardware steering feature is much older than z14. > > > > Several years ago, we had a TOD clock that was a couple minutes off. We > > wanted to issue the command (HMC?) that would steer the clock to correct > > But we were blocked by a software validity check that would not accept > > such a large correction. We instructed our operator to apply the maximum > > permitted correction every couple days. > > > > I suspect that the "z14 announcement??" might merely remove the maximum > > adjustment limit. > > > > How does this play with OMVS? > > > > Does the TIME macro's SVC have code to ensure that STCK and fetch > > CVTLSO don't happen on opposite sides of a leap second? > > > > -- gil > > > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
