On 4/14/25 10:40, Jonathan Scott wrote:
A TOD clock value overflows after that date and time regardless of timezone;
...
That's pedantry. I believe that if the TOD clock is set according to thr
recommendation in the PoOp, TAI-10 seconds, it will overflow ata
(if I have calculated correctly):
2042-09-17T23:53:57.370496 TAI
2042-09-17T23:53:20.370496 UTC
2042-09-17T17:53:20 Zoom out.370496 MDT (my timezone)
If no additional leap seconds occur before2042.
Simply, if TODD is set as PoOp recommends, timezone matters,
....
that's the date and time value represented by the highest unsigned value. The
usual convention is that the hardware clock is set to UTC. However, local
times represented in TOD format will of course overflow at the same clock value
in local time, which may be before or after that time in UTC.
....
UTC or TAI-10?
<https://datacenter.iers.org/data/latestVersion/bulletinC.txt>
On 4/14/25 10:05, James Mulder wrote:
z/OS systems lacking sign comparator support will be out of support long
before 2042.
As for machines, z13 was the last machine which doesn't have signed comparator,
and z/OS 2.5 (which goes out of support in 2026) is that last release of z/OS
that will run on a z13.
...
I can think of two ways an epoch 0 TOD value with positive sign could occur:
o A programmer uses CONVtOD to synthesize a TOD value for a data base.
My date of birth would be such.
o A programmer has saved the value loaded in the comparator after 2042
and attempts to convert it back to displayable time.
No algorithm in STCKCONV can give correct results for both cases.
It would be prudent design for STCK to set error status for nonzero
epoch index.
--
Thanks,
gil
