> STCKF is better for cases where you do not need that uniqueness Can't emphasize that enough. If you are using STCK and all you need is "the time," not "a time that is not identical to any other possible STCK" then you are wasting LOTS of CPU cycles -- use STCKF instead.
In fact, I guess you could extend that to say that *every* STCK is probably a waste of CPU time. If you don't need a unique time, use STCKF. If you DO need a unique time, modify your logic to allow the use of STCKE. (STCKF is "plug compatible" with STCK; STCKE is not.) Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Sunday, March 21, 2021 6:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Contents of TOD Programmable Field under z/OS? The STCKE result, like the STCK result, is architecturally guaranteed to be unique across all the CPUs used by an operating system image (i.e., within an LPAR). This is not a sysplex statement; sysplex is not an architectural construct. The STCKF result, on the other hand, is not guaranteed unique; using STCKF is better for cases where you do not need that uniqueness. The STCK instruction might have to spin in some cases where the same CPU issues consecutive STCK's very close together. STCKE theoretically might have to do so too but in practice I think does not, due to the significantly greater granularity. Peter Relson ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
