That problem is not limited to transaction programs that issue STCK repeatedly, or that have some sort of internal "is this value unique?" logic. *Any* time that you issue STCK you run the risk that some program -- your program or some other unrelated program -- has recently issued an STCK and your program must spin, consuming CPU cycles, until a unique STCK value is available. If you are responsible for a program that issues STCK, and you do not need a unique monotonic value, replace the STCK with an STCKF. It's a perfectly plug-compatible one-to-one replacement, and it never spins waiting for the clock to tick.
OTOH, if you do need a monotonic value, then you should redesign and recode to use STCKE. Charles On Mon, 19 Feb 2024 17:09:53 -0600, Joel C. Ewing <[email protected]> wrote: <snip ...> >I vaguely recall an instance, probably at least 30 years ago, when after >a processor upgrade the MSU usage per transaction of some applications >unexpectedly increased with the faster CPU. It was eventually found >that the application design had needed a unique monotone increasing ID >for some transactions and they just relied on a clock-based value to a >resolution that was more than adequate originally. The processor power >and transaction rate had finally crossed a threshold where it had become >a regular occurrence for the application to enter a retry loop until the >clock changed enough to generate a unique ID so the transaction could >successfully complete! ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
