Yes, 1/2 epoch windowing, which is around 71 years.
Yes, FFFFFFFFFFFFFFFF and 0000000000000000 can no longer be used for "never"
and "immediately" when a signed or windowed compare might be done. Even
without the clock comparator control register 0 bit set to do signed compares,
there may be software which is getting changed to do signed or windowed
compares. We have already started working on that in z/OS, and changing usage
of 0000000000000000 and FFFFFFFFFFFFFFFF is one if the things to deal with.
I have been using the current time from STCKF for "immediately" and current
time + almost 1/2 epoch for "distant future".
For two timestamps which are known to be within 71 years of each other (as
would be the case for two timestamps from the same IPL of a system), one
convenient technique is to change
IF Timestamp1 CompareOp Timestamp2 THEN
To
IF Signed_Of(Timestamp1 - Timestamp2) CompareOp 0 THEN
Or in assembler,
LG Rx,Timestamp1
SLG Rx,Timestamp2
LTGR Rx,Rx
Jxx somelabel where xx depends on the CompareOp
Jim Mulder
-----Original Message-----
From: IBM Mainframe Assembler List <ASSEMBLER-LIST@LISTSERV.UGA.EDU> On Behalf
Of Paul Gilmartin
Sent: Saturday, April 12, 2025 1:03 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Store-Clock-Fast Facility
On 4/11/25 22:42, James Mulder wrote:
<snip!> But thanks for all that.
> This bigger concern for programs that use STCK or STCKF is the TOD clock
> wrap in September 2042. Any code that uses a logical compare (like CLC) for
> two timestamps will get the wrong result when one timestamp is before the wrap
> and the other is after. So there is a lot of code in operating systems,
> middleware, and probably applications, that needs to be changed to use a
> different comparison technique before then.
> ...
Doesn't the Clock Comparator already employ windowing? How long?
70 years? That would already impact programmers who naively use a hard-coded
x'FFFFFFFF' to mean "never" or x')00000000' to mean "immediately."
--
gil
