If I remember correctly, the timestamp runs from 1900 to 2042, checking 1 high bit gives you 2 X 71 year epochs, 2 high bits gives 4 X 35.5 year epochs, 3 high bits gives 8 X 15.75 year epochs, 4 high bits 16 X 7.875 year epochs.
Suggest checking 2 high bits, treating current and past 2 epochs (71- 106.5 years) as valid, and the next epoch as past data that needs to be cleared before reuse. From now to 2042, the future epoch of b'00'did represent 1900-1935 so no past data, but starting in 2042 the next epoch of B'01' currently used to represent 1936-1971 and might have some data to be flagged. On Wed, Jun 12, 2024 at 6:56 AM Peter Relson <[email protected]> wrote: > > <snip> > Am I correct in understanding that on current hardware an overflow from the > TOD > will be carried into the Epoch Index, but only once? > </snip> > No, that is not correct. The Epoch Index gets incremented upon the > wrap/overflow, for as many epochs as happen. > > <snip> > Am I correct in understanding that the Clock Comparator remains in 64-bit > TOD format? How will intervals spanning that time in 2042 be handled? > </snip> > Yes, it is true. The short answer to the second question is "correctly". > As a hint, try doing 64-bit arithmetic that subtracts a before-wrap 8-byte > TOD value from an after-wrap 8-byte TOD value and see what you get. > > Peter Relson > z/OS Core Technology Design > > > ---------------------------------------------------------------------- > 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
