The finer granularity of STCKE is sufficient to not require a significant delay to achieve uniqueness.
My general rule is that if you need to generate a unique token, use STCK or STCKE. If you just need to know what time it is, use STCKF or STCKE. The complex "time appears to run backward" scenarios with STCKF involve two programs running concurrently on different CPUs using the same storage. I have never seen the cases of concern in any code I have worked with. For time stamps that a used by a single thread, any undispatch and redispatch by an operating system or hypervisor takes longer than the low order bits that STCK usurps for uniqueness purposes. 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. Jim Mulder -----Original Message----- From: IBM Mainframe Assembler List <[email protected]> On Behalf Of Paul Gilmartin Sent: Friday, April 11, 2025 2:29 PM To: [email protected] Subject: Re: Store-Clock-Fast Facility On 4/11/25 11:38, Mario Bezzi wrote. > @Charles: You make a good point about STCKE, but I was under the impression, > confirmed by a quick check that as STCK, it also requires synchronization. > ... Yes, but because of the finer granularity of the ETOE, the serialization is likely to take less time. This is probably model-dependent, and documented somewhere. How much STCK(E) activity do you expect and how much will you suffer? > "A serialization function is performed before the value of the clock is > fetched and again after the value is placed in storage" > -- gil
