On Thu., Nov. 12, 2020, 14:59 Peter Relson, <[email protected]> wrote:
> >> Perhaps the TOD clock is slowed or stalled for leap seconds, to keep > >> TOD-derived date and time in synch with solar time? > >> > >Correct. > > I'd have answered "Not correct". When the leap second change is > introduced, yes, this sort of thing might happen. > But only during that time. > > Does the OP know that their system has leap seconds in effect? > Does the operating system agree (what's the value in CVTLSO)? > > Peter Relson > That's the question. I'm trying to build an understanding of the issues that works (for me) across the range from Hercules/MVS3.8 to recent z/OS. It seems that, if used, CVTLSO should be the gap between TOD/ETOD and UTC, and STCKCONV (if available) uses it to get the correct time. The only alternative I can see, to keep TOD valid for conversion to time & date, is to slow it down to close the gap, quietly forgetting the leap seconds ever happened. It's interesting to me because I've seen a lot of code using TOD clock just to display "12:25" on some report where I'd probably have let the system work it out for me (using TIME DEC in assembly, or some language feature). And it's interesting on a human scale, becuse there are enough leap seconds to get the minute wrong. "Why is your information a minute newer than mine?" (my MVS 3.8 doesn't have CVTLSO, or anything similar as far as I can see. But I could add a similar feature, if it mattered enough. I could add a control block for holding 'installation' data in CSA, using CVTUSER as a pointer :-) ) Roops > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
