On Tue, 16 Jun 2020 14:16:13 +0300, Steff Gladstone wrote:
>We need to capture the date and time in a GLUE and need more precision than
>the CICS variables give us.
>
There's a possible timing window in naive leap second
correction. Suppose:
STCK
(a leap second occurs, adding 1 to CVTLSO)
Programmer subtracts CVTLSO from stored TOD value
resulting in a time value 0.99 seconds early.
If thw programmer reverses the order of operations, the
complementary hazard giving a timne 0.99 seconds in the
future exists.
This can be avoided by:
RETRY: Copy CVTLSO
STCK
IF CVTLSO<>Copy GOTO RETRY
Subtract CVTLSO from stored TOD
Does TIME macro do something similar? It's a performance
cost of two (three?) instructions in a much-used code
path to avoid a hazard that occurs only every year or
two. But this has caused servers to crash.
Wrapping the operations with a lock would be more costly.
Amazon, Google, (Others?) "smear" leap seconds over 24
hours to avoid this:
https://en.wikipedia.org/wiki/Leap_second#Workarounds_for_leap_second_problems
This requires steering the clock by 12 ppm, well within
the capability of the TOD clock, but for z/OS to freeze
CVTLSO at its current value and to adopt smearing would
be a major change from specified behavior.
(I submitted my RCF on STCKCONV.)
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
