For a finite state space, you don't need statistics to guaranty collisions. Statistics comes in when you have a string of samples too short to guaranty collisions and want to know what the probability of collisions is. For some applications a probability of e.g., .1 (10%), might be acceptable while for others it is intolerable.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [[email protected]] on behalf of Timothy Sipples [[email protected]] Sent: Sunday, March 21, 2021 11: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
