On Sat, 18 Jul 2026 15:59:06 -0500, Paul Gilmartin <[email protected]> wrote:
>A step in deriving GMT from TOD is to subtract CVTLSO. I assume the TIME >macro does this. And user processes are made non-dispatchable curing a >leap second for timestamp consistency. > >But I imagine a remaining race condition. If CVTLSO is accessed and STCK >is issued on opposite sides of a leap second, the derived GMT can be in >error by nearly a second. That could be avoided by: >TRY fetch CVTLSO > STCK > compare fetched value to CVTLSO > BNE TRY I did that sort of thing on a CMS system IIRC where I needed millisecond resolution. I had one API that gave me TOD and one that gave me STCK. I called TOD, then STCk, then TOD to see if it had changed. Seemed to work well. >Two additional instructions for a hazard that occurs only every few months. Or not at all: https://www.livescience.com/goodbye-leap-second-2035 >Does TIME macro do that? Is there a better way? > >Good practice might be to store not GMT but TOD in critical data bases That's what the new extended SMF records do: 28 1C SMF1153_HDR_STCKE 16 binary Time when the record was written, in STCKE format. Charles ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
