A 64 bit (or longer) binary counter? > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On > Behalf Of Timothy Sipples > Sent: Sunday, March 21, 2021 8:44 PM > To: [email protected] > Subject: Re: Contents of TOD Programmable Field under z/OS? > > It's possible for a random number generator to produce duplicate output. > Statistically speaking, a duplicate (random number collision) is > guaranteed if you keep generating random numbers and merely wait long > enough. If you combine a time of day number (which is generally assumed > monotonically increasing, unless someone does something particularly > "clever") with a "long" random number then collisions are improbable but > technically not altogether impossible. > > Do you need *guaranteed* uniqueness? If you do, the Db2 suggestion is a > very good one if you have Db2 or get it. Broadly comparable facilities are > available in MQ if you want a guarantee of Sysplex-wide uniqueness. (This > is a well solved problem in z/OS-based middleware.) Or you could check > each new time+random value against running lists of past time+random > values where time=time, discarding the prior list when new time > old > time. This roll-your-own approach takes some effort if you want it to be > robust. > > Yet another approach is that you voluntarily allow and require time to > elapse before generating the next time+random value. If you wait long > enough, there's no time collision. But then you probably wouldn't use a > random add-on but rather a dimensionally "big" sequence string, unless the > random portion is somehow useful. For example your string could be in the > format: > > A + B + C > > where A is the finest grained time of day you can get, B is a unique > program instance ID (e.g. in a 2-way Sysplex with a maximum of 2 instances > of the program running, this could be "X" or "Y"), and C is a "long" > sequence string. While A = A, you simply increment through C. In the > extraordinarily improbable event you ever get to the end of C (since > you've made it dimensionally big enough for even Year 8000 computing > power), you refuse to keep processing and yield even discretionary > dispatching until A must have incremented. (Which you still verify with an > A new v. A prior comparison.) > > Or, instead of an explicit B, you vary the C list depending on program > invocation context, which amounts to the same thing. > > Lots of options! I don't quite understand the end goal, though, so it's a > bit difficult to decide which one of these approaches, or some other, is > the best fit. > > - - - - - - - - - - > Timothy Sipples > I.T. Architect Executive > Digital Asset & Other Industry Solutions > IBM Z & LinuxONE > - - - - - - - - - - > E-Mail: [email protected] > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
