The only reliable way to generate monotonicity in a transaction field
for an application that's going to be around for a number of years is to
use a counter whose increment is properly serialized. If you try to
use a clock value for this, you have to pick some fixed resolution, and
history guarantees that what works today will at some point in the
future fail.
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!
JC Ewing
On 2/18/24 20:34, Paul Gilmartin wrote:
On Sun, 18 Feb 2024 18:22:53 -0600, Peter Farley wrote:
The only HLL-callable function already provided in z/OS that I can find that
provides anything near that resolution is the LE Callable Services function
CEEGMT, but two calls to that service from a COBOL program in a row separated
by only a few calculations and a DISPLAY to SYSOUT produce identical values.
This is not good enough for high-volume processing needs. Every request for a
time value needs to generate a new higher value.
What guarantees uniqueness other than STCT(E)? Does the Sysplex Timer/ETR
guarantee
uniqueness across the plex?
And monotonicity is a harsher constraint. In the Bad Old Days when each CPU
had its own
TOD and uniqueness was achieved by putting the CPU ID in the TOD programmable
field
I wondered hereabouts whether a later transaction on a lower CPU could get lower
timestamp than an earlier transaction on a higher CPU.
And even if a service such as STCKE returns unique values, conversion to
displayable
nanoseconds can result in duplicates.
You need a serialized service common to all participating processes that
returns unique
values in a specified format. Performance may suffer.
--
Joel C. Ewing
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
