On 2021-03-21, at 07:52:27, Peter Relson wrote:
> 
> The software will not have to do anything in order to get the epoch index 
> to increase to 1 in September 2042. ...
>  
Thanks.  I saw that cleearly in the PoOps.

> The clock comparator remains an 8 byte entity. But the OS will be able to 
> indicate that the CC is to be treated as signed, so that 00000000_00000000 
> will be "later" than (the negative) FFFFFFFF_FFFFFFFF. That exploitation 
> of the multiple epoch facility does require OS action. And probably 
> requires a converse action every 70 years or so when the high bit of the 
> TOD clock changes.
>  
I had envisioned a ±70-year window implemented by continually performing
a Subtract Logical TOD - Comparator and testing the sign.  The behavior
would be more continuous, not requiring "action every 70 years or so".

Any implementation is likely to have hazards when:

o A programmer sets comparator to 0 to indicate "immediately".

o A programmer sets comparator to maximum to indicate "never".

o An expiry time is set very near maximum and the CPU is not
  dispatchable at that time.

There is a legend (reported here a few years ago?) of a program
that used a value of decimal one billion to indicate "never"
and looped when that time occurred.

Thanks again,
gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to