Re: Contents of TOD Programmable Field under z/OS?
On Mon, 22 Mar 2021 03:51:50 +, Gibney, Dave wrote: >A 64 bit (or longer) binary counter? > Consider the Pigeonhole Principle. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
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 [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Timothy Sipples [sipp...@sg.ibm.com] Sent: Sunday, March 21, 2021 11:44 PM To: IBM-MAIN@LISTSERV.UA.EDU 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: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
A 64 bit (or longer) binary counter? > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Timothy Sipples > Sent: Sunday, March 21, 2021 8:44 PM > To: IBM-MAIN@LISTSERV.UA.EDU > 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: sipp...@sg.ibm.com > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
> 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
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 z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
On Sat, 20 Mar 2021 10:42:46 -0700, Charles Mills wrote: >STCKE is I believe guaranteed unique by architecture. Db2 would fall on its >face without that. > Understood, but I know no guarantee that any proper substring of the STCKE value is unique. >-Original Message- >From: Paul Gilmartin >Sent: Friday, March 19, 2021 9:24 PM >> >Peter R's statement implies that no proper substring of the STCKE value is >guaranteed unique. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
STCKE is I believe guaranteed unique by architecture. Db2 would fall on its face without that. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353 Sent: Friday, March 19, 2021 9:55 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Contents of TOD Programmable Field under z/OS? In reverse order of your questions: Sorry, I am not free to discuss the actual application details. And I did not get that from Peter R.'s statement -- quite the contrary in fact. With the z/OS generated programmable field LPAR value (whatever it may be), the STCKE result is in fact guaranteed unique in a sysplex. Considering that byte 0 of the STCKE result is the epoch index and thus is zero until 2042 and that byte 1 (byte 0 of the TOD clock) changes in far more than one 24 hour period, bytes 2-10 or 11 of the STCKE result combined with byte 15 can comprise quite a reasonably unique value when results only have to be unique for the day. Not guaranteed perhaps, but "good enough". I ran 100 billion loops returning a value constructed from the STCKE result and got no duplicate values. Admittedly this was done with a COBOL driver and a dynamically loaded STCKE subroutine, so it's probable the result location was not in the same cache line as the STCKE, so not as stressful a test as one could possibly construct, but definitely more stressful than the environment in which the real world application lives, so I'm good with that. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Friday, March 19, 2021 9:24 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Contents of TOD Programmable Field under z/OS? On Fri, 19 Mar 2021 22:55:25 +, Farley, Peter x23353 wrote: >Sounds to me like the first 12 bytes of STCKE plus the last byte of the >"programmable field" in the STCKE result. > Peter R's statement implies that no proper substring of the STCKE value is guaranteed unique. It's surprising that any process requires so many UUIDs that performance is a concern. Must the values be sortable in chronological order? Are you free to disclose the maximum permitted value of your UUIDs? -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
On Sat, 20 Mar 2021 04:54:34 +, Farley, Peter x23353 wrote: >In reverse order of your questions: > Why not write each answer after the matching question as was once the custom? It's easier to read that way. >Sorry, I am not free to discuss the actual application details. > >And I did not get that from Peter R.'s statement -- quite the contrary in >fact. With the z/OS generated programmable field LPAR value (whatever it may >be), the STCKE result is in fact guaranteed unique in a sysplex. > Peter R. carefully made no assertion of concerning the format of the programmable field, nor that uniqueness is guaranteed when bits 0-7 (byte 14 stored by STCKE) are ignored. >Considering that byte 0 of the STCKE result is the epoch index and thus is >zero until 2042 and that byte 1 (byte 0 of the TOD clock) changes in far more >than one 24 hour period, bytes 2-10 or 11 of the STCKE result combined with >byte 15 can comprise quite a reasonably unique value when results only have to >be unique for the day. Not guaranteed perhaps, but "good enough". > That "unique for the day" is "good enough" depends on your application details. What about bytes 12-13. PoOps "Figure 4-12. Format of the TOD Clock, ..." leads me to conclude that all of Epoch Index, 104-bit TOD Clock, and Programmable Field must be considered to guarantee uniqueness. >I ran 100 billion loops returning a value constructed from the STCKE result >and got no duplicate values. Admittedly this was done with a COBOL driver and >a dynamically loaded STCKE subroutine, so it's probable the result location >was not in the same cache line as the STCKE, so not as stressful a test as one >could possibly construct, but definitely more stressful than the environment >in which the real world application lives, so I'm good with that. > And what about the next OS release and the next hardware model? I'll suggest taking all 16 bytes stored by STCKE, converting to a 32-byte hex string, and using that as a UUID. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
-- It appears that the "uniqueness" applied by the programmable field is limited to the sysplex. It has nothing to do with an LPAR (aside from that z/OS runs within one). There is no uniqueness across sysplexes. -- It appears that the current implementation uses the "system number" managed by XCF (so the limit is the number of systems within a sysplex). -- It appears that there is no guarantee of uniqueness until such time as that system number is determined (which is early in IPL but is later than when it is allowed to issue STCKE). Perhaps someone could share how they can make productive use of this level of uniqueness (and, in effect, why they care). That would be good rationale for understanding the importance of documenting whatever guarantee of uniqueness z/OS implements. A timestamp "later" than another timestamp (when looking at all the bits, including the programmable field) does not mean that the event correlated with that later time happened after the even correlated with the earlier time, unless there is sysplex-wide serialization (as might be held when writing to the couple data set, but I'd think it likely that the programmable field is not needed for uniqueness in that case) Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
Peter, I don't know if this could be the base of what you need, however I'd like to point you to a github page for something that Walmart did for generating unique zUID, guaranteed to be unique until the year 34,000 (built with patent pending algorithm). It was built as a cloud solution, however it says in the initial page that it can be called from a cics program. Here's the link: https://github.com/walmartlabs/zUID Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
In reverse order of your questions: Sorry, I am not free to discuss the actual application details. And I did not get that from Peter R.'s statement -- quite the contrary in fact. With the z/OS generated programmable field LPAR value (whatever it may be), the STCKE result is in fact guaranteed unique in a sysplex. Considering that byte 0 of the STCKE result is the epoch index and thus is zero until 2042 and that byte 1 (byte 0 of the TOD clock) changes in far more than one 24 hour period, bytes 2-10 or 11 of the STCKE result combined with byte 15 can comprise quite a reasonably unique value when results only have to be unique for the day. Not guaranteed perhaps, but "good enough". I ran 100 billion loops returning a value constructed from the STCKE result and got no duplicate values. Admittedly this was done with a COBOL driver and a dynamically loaded STCKE subroutine, so it's probable the result location was not in the same cache line as the STCKE, so not as stressful a test as one could possibly construct, but definitely more stressful than the environment in which the real world application lives, so I'm good with that. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Friday, March 19, 2021 9:24 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Contents of TOD Programmable Field under z/OS? On Fri, 19 Mar 2021 22:55:25 +, Farley, Peter x23353 wrote: >Sounds to me like the first 12 bytes of STCKE plus the last byte of the >"programmable field" in the STCKE result. > Peter R's statement implies that no proper substring of the STCKE value is guaranteed unique. It's surprising that any process requires so many UUIDs that performance is a concern. Must the values be sortable in chronological order? Are you free to disclose the maximum permitted value of your UUIDs? -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
On Fri, 19 Mar 2021 22:55:25 +, Farley, Peter x23353 wrote: > >The GENERATE_UNIQUE function returns a bit data character string 13 bytes long >(CHAR(13) FOR BIT DATA) that is unique compared to any other execution of the >same function. The function is defined as not deterministic. Although the >function has no arguments, the empty parentheses must be specified when the >function is invoked. >The result of the function is a unique value that includes the internal form >of the Universal Time, Coordinated (UTC) and, if in a sysplex environment, the >sysplex member where the function was processed. >The result cannot be null. >The result of this function can be used to provide unique values in a table. >The sequence is based on the time when the function was executed. > Does "based" imply relative to the first call to the function? >Sounds to me like the first 12 bytes of STCKE plus the last byte of the >"programmable field" in the STCKE result. > Peter R's statement implies that no proper substring of the STCKE value is guaranteed unique. It's surprising that any process requires so many UUIDs that performance is a concern. Must the values be sortable in chronological order? Are you free to disclose the maximum permitted value of your UUIDs? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
Thanks Charles, I did already think of that, and it has performance disadvantages that I can't ignore. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Friday, March 19, 2021 4:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Contents of TOD Programmable Field under z/OS? @Peter do you mean alphanumeric (A-Z, 0-9) or do you mean "any bit combination 00 to FF"? I read it as "any bits" but you did say alphanumeric. If you mean alphanumeric then you need a table of the 36 or 62 or whatever characters comprise your set. Then take my method, generate a number 0 to 35 or 61, and use it to index into the table, and store that in each character position. Alphanumeric guaranteed. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, March 19, 2021 11:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Contents of TOD Programmable Field under z/OS? On Fri, 19 Mar 2021 18:20:04 +, Farley, Peter wrote: > >The actual application requirement is for alphanumeric random values of a >certain length. I can’t say more than that without revealing company IP. > 708 $ head -c16 /dev/random | uuencode -m Random.string begin-base64 644 Random.string bpREwrn14giB65RLelIW5A== (but alphanumeric not guaranteed.) -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
Thanks for the idea Gil, but I need guaranteed alphanumeric (upper case letters plus digits, nothing else). Plus invoking z/OS *nix services dynamically is not cheap either. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Friday, March 19, 2021 2:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Contents of TOD Programmable Field under z/OS? On Fri, 19 Mar 2021 18:20:04 +, Farley, Peter wrote: > >The actual application requirement is for alphanumeric random values of a >certain length. I can’t say more than that without revealing company IP. > 708 $ head -c16 /dev/random | uuencode -m Random.string begin-base64 644 Random.string bpREwrn14giB65RLelIW5A== (but alphanumeric not guaranteed.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
Yes, but then we have to have a loop to call random, multiply by 100, use the integer value of the result to pick a random character from the allowed ones for the field to be filled, with as many iterations as the length of the field. Not cheap. One STCKE is far easier and quicker. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Friday, March 19, 2021 2:51 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Contents of TOD Programmable Field under z/OS? If it is like the crypto things I am familiar with, you could simulate it by generating a RANDOM value and multiplying by 255 or 256 (depending on the exact specs for RANDOM, which I do not have open at the moment) to get a value between 0 and 255. Do that repeatedly until you have a string of the length you need. It will not be crypto quality. It will be adequate for testing (but watch out for the tendency of things that work in test to move into production unchanged). If you need crypto quality, there is no substitute for a crypto quality true random number generator. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353 Sent: Friday, March 19, 2021 11:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Contents of TOD Programmable Field under z/OS? Charles, The actual application requirement is for alphanumeric random values of a certain length. I can’t say more than that without revealing company IP. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Friday, March 19, 2021 1:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Contents of TOD Programmable Field under z/OS? > that only returns a fraction between 0 and 1, which could be useful > but quite a bit more work What do you need? An integer between 0 or 1 and 'n'? Multiplying the result of RANDOM times 'n' should give you that integer pretty readily, no? This may not give you crypto quality, but the idea is right. What am I missing? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353 Sent: Friday, March 19, 2021 8:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Contents of TOD Programmable Field under z/OS? Update: It seems we are on z13 boxes at the moment, and they do not have the Message-Security-Assist Extension 7 feature necessary to use the TRNG functions of PRNO. I could try the DRNG functions of PRNO but they seem to be a lot of work to use the right way (seeding, parameter blocks, etc.). It would be far easier to use the COBOL RANDOM intrinsic, but that only returns a fraction between 0 and 1, which could be useful but quite a bit more work to incorporate into the application function at issue. Lacking the COBOL UUID4 function here, the KISS principle says STCKE it will be for now. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
Thanks Salva, but as I said in my prior reply, this is not a case where DB2 is already in use. The additional overhead to use DB2 for this would be far too large. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Salva Carrasco Sent: Friday, March 19, 2021 2:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Contents of TOD Programmable Field under z/OS? Peter, Cobol UUID4 (available in 6.3) had a horrible performance on a z13. In z15, the performance is excellent. We opened a SR and they tell us about the random number generator. If you can't wait and have Db2, I wrote a Db2 Funct to generate UUID based on TOD. It is available in https://urldefense.com/v3/__https://github.com/salva-rczero/Db2Functs__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!bCD5fmMuILDyjE79RSciUFpZkrh4i2-_wegcax59ksCzii9Ga3lzg_g1ngbi7VsWVVb8NQ$ regards, salva. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
Thanks for the reference. I see from the DB2 documentation that: The GENERATE_UNIQUE function returns a bit data character string that is unique, compared to any other execution of the same function. GENERATE_UNIQUE() The schema is SYSIBM. The GENERATE_UNIQUE function returns a bit data character string 13 bytes long (CHAR(13) FOR BIT DATA) that is unique compared to any other execution of the same function. The function is defined as not deterministic. Although the function has no arguments, the empty parentheses must be specified when the function is invoked. The result of the function is a unique value that includes the internal form of the Universal Time, Coordinated (UTC) and, if in a sysplex environment, the sysplex member where the function was processed. The result cannot be null. The result of this function can be used to provide unique values in a table. The sequence is based on the time when the function was executed. Sounds to me like the first 12 bytes of STCKE plus the last byte of the "programmable field" in the STCKE result. That looks like lots of overhead to connect to and call a DB2 function when a simple STCKE gets you the same information. The application program at issue is not already using DB2, so this one is not in the running on a performance basis alone. If the program needing the value was already using DB2, maybe not so bad, but in my case it is not already accessing DB2. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Salva Carrasco Sent: Friday, March 19, 2021 2:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Contents of TOD Programmable Field under z/OS? Peter, GENERATE UNIQUE Db2 function, warrants the uniqueness aceoss a Sysplex and it is based on TODE. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
@Peter do you mean alphanumeric (A-Z, 0-9) or do you mean "any bit combination 00 to FF"? I read it as "any bits" but you did say alphanumeric. If you mean alphanumeric then you need a table of the 36 or 62 or whatever characters comprise your set. Then take my method, generate a number 0 to 35 or 61, and use it to index into the table, and store that in each character position. Alphanumeric guaranteed. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, March 19, 2021 11:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Contents of TOD Programmable Field under z/OS? On Fri, 19 Mar 2021 18:20:04 +, Farley, Peter wrote: > >The actual application requirement is for alphanumeric random values of a >certain length. I can’t say more than that without revealing company IP. > 708 $ head -c16 /dev/random | uuencode -m Random.string begin-base64 644 Random.string bpREwrn14giB65RLelIW5A== (but alphanumeric not guaranteed.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
On Fri, 19 Mar 2021 18:20:04 +, Farley, Peter wrote: > >The actual application requirement is for alphanumeric random values of a >certain length. I can’t say more than that without revealing company IP. > 708 $ head -c16 /dev/random | uuencode -m Random.string begin-base64 644 Random.string bpREwrn14giB65RLelIW5A== (but alphanumeric not guaranteed.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
If it is like the crypto things I am familiar with, you could simulate it by generating a RANDOM value and multiplying by 255 or 256 (depending on the exact specs for RANDOM, which I do not have open at the moment) to get a value between 0 and 255. Do that repeatedly until you have a string of the length you need. It will not be crypto quality. It will be adequate for testing (but watch out for the tendency of things that work in test to move into production unchanged). If you need crypto quality, there is no substitute for a crypto quality true random number generator. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353 Sent: Friday, March 19, 2021 11:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Contents of TOD Programmable Field under z/OS? Charles, The actual application requirement is for alphanumeric random values of a certain length. I can’t say more than that without revealing company IP. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Friday, March 19, 2021 1:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Contents of TOD Programmable Field under z/OS? > that only returns a fraction between 0 and 1, which could be useful > but quite a bit more work What do you need? An integer between 0 or 1 and 'n'? Multiplying the result of RANDOM times 'n' should give you that integer pretty readily, no? This may not give you crypto quality, but the idea is right. What am I missing? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353 Sent: Friday, March 19, 2021 8:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Contents of TOD Programmable Field under z/OS? Update: It seems we are on z13 boxes at the moment, and they do not have the Message-Security-Assist Extension 7 feature necessary to use the TRNG functions of PRNO. I could try the DRNG functions of PRNO but they seem to be a lot of work to use the right way (seeding, parameter blocks, etc.). It would be far easier to use the COBOL RANDOM intrinsic, but that only returns a fraction between 0 and 1, which could be useful but quite a bit more work to incorporate into the application function at issue. Lacking the COBOL UUID4 function here, the KISS principle says STCKE it will be for now. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
Peter, Cobol UUID4 (available in 6.3) had a horrible performance on a z13. In z15, the performance is excellent. We opened a SR and they tell us about the random number generator. If you can't wait and have Db2, I wrote a Db2 Funct to generate UUID based on TOD. It is available in https://github.com/salva-rczero/Db2Functs regards, salva. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
Peter, GENERATE UNIQUE Db2 function, warrants the uniqueness aceoss a Sysplex and it is based on TODE. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
Charles, The actual application requirement is for alphanumeric random values of a certain length. I can’t say more than that without revealing company IP. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Friday, March 19, 2021 1:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Contents of TOD Programmable Field under z/OS? > that only returns a fraction between 0 and 1, which could be useful > but quite a bit more work What do you need? An integer between 0 or 1 and 'n'? Multiplying the result of RANDOM times 'n' should give you that integer pretty readily, no? This may not give you crypto quality, but the idea is right. What am I missing? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353 Sent: Friday, March 19, 2021 8:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Contents of TOD Programmable Field under z/OS? Update: It seems we are on z13 boxes at the moment, and they do not have the Message-Security-Assist Extension 7 feature necessary to use the TRNG functions of PRNO. I could try the DRNG functions of PRNO but they seem to be a lot of work to use the right way (seeding, parameter blocks, etc.). It would be far easier to use the COBOL RANDOM intrinsic, but that only returns a fraction between 0 and 1, which could be useful but quite a bit more work to incorporate into the application function at issue. Lacking the COBOL UUID4 function here, the KISS principle says STCKE it will be for now. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
> that only returns a fraction between 0 and 1, which could be useful but quite > a bit more work What do you need? An integer between 0 or 1 and 'n'? Multiplying the result of RANDOM times 'n' should give you that integer pretty readily, no? This may not give you crypto quality, but the idea is right. What am I missing? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353 Sent: Friday, March 19, 2021 8:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Contents of TOD Programmable Field under z/OS? Update: It seems we are on z13 boxes at the moment, and they do not have the Message-Security-Assist Extension 7 feature necessary to use the TRNG functions of PRNO. I could try the DRNG functions of PRNO but they seem to be a lot of work to use the right way (seeding, parameter blocks, etc.). It would be far easier to use the COBOL RANDOM intrinsic, but that only returns a fraction between 0 and 1, which could be useful but quite a bit more work to incorporate into the application function at issue. Lacking the COBOL UUID4 function here, the KISS principle says STCKE it will be for now. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
Update: It seems we are on z13 boxes at the moment, and they do not have the Message-Security-Assist Extension 7 feature necessary to use the TRNG functions of PRNO. I could try the DRNG functions of PRNO but they seem to be a lot of work to use the right way (seeding, parameter blocks, etc.). It would be far easier to use the COBOL RANDOM intrinsic, but that only returns a fraction between 0 and 1, which could be useful but quite a bit more work to incorporate into the application function at issue. Lacking the COBOL UUID4 function here, the KISS principle says STCKE it will be for now. Thanks all for the discussion and recommendations. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter x23353 Sent: Friday, March 19, 2021 4:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Contents of TOD Programmable Field under z/OS? Thanks Ed, I hadn't actually looked at the RNG capabilities in CPACF in recent times. From an initial once-over of the TRNG capability described in the latest PoOP, it may be a better source of data than STCKE for my application. I will need to make some performance measurements to make sure I am not slowing the application process flow too much. The COBOL UUID4 function may be the "future state" version for my application requirements, once we are up to date enough to use it. That will need some performance measuring too once we are there. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Ed Jaffe Sent: Thursday, March 18, 2021 10:06 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Contents of TOD Programmable Field under z/OS? On 3/18/2021 6:38 PM, Paul Gilmartin wrote: > > Using clock values as a source of entropy is discouraged. If a > (fe)malefactor can make a good guess at an interval during which the > clock is sampled there's little entropy available. IBM Z was recently enhanced with a true random source in CPACF. For all the many decades before that, all "random" numbers on the mainframe were actually pseudo-random... -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
Regarding the questions about order of clock values in a multi-system environment, if you want/need such ordering, you should use the STCKSYNC service. It has never been clear to me how useful that is since the saving of the time and the processing of the event are not atomic. There are likely thousands of things within the operating system that are done in order to meet architectural requirements. They are not documented as such. That is why there is an operating system, so you don't have to deal with them. If the architecture indicates that something needs to be done, it is done. If there is architectural flexibility in "how" then the OS might take advantage of that. If we thought it appropriate for someone to code to it, then it could be an interface. For the programmable field of the clock, we do not. It is just more bits. If someone makes a case that it can help with diagnosis to understand (but not code to), then we would consider documenting (in a diagnosis guide) the current, but could change at any time, implementation. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TRNG (was: Contents of TOD Programmable Field under z/OS?)
W dniu 19.03.2021 o 12:59, Paul Gilmartin pisze: On Fri, 19 Mar 2021 14:43:05 +0800, Timothy Sipples wrote: ... Paul Gilmartin wrote: The latter suggests that a pseudo RNG is periodically reseeded by the TRNG Yes, that's right. CPACF on the IBM z14 and LinuxONE II models, and higher, have this feature. If you try to use the TRNG for every random number request it's really slow, but fortunately that's not required to achieve the desired, certified outcome. Seeding is rather important, though, and that's why they're there. Thanks. UNIX has long had /dev/random, a TRNG (subject to hardware availability) and /dev/urandom, a seeded PRNG. For a while I had a Solaris tower under my desk. The perceptible difference was that "cat /dev/random >/dev/null" caused the fan to speed up audibly; "cat /dev/urandom >/dev/null" was silent. Didn't you get B37 abend on /dev/null dataset? ;-) -- Radoslaw Skorupka (looking for new job) Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
TRNG (was: Contents of TOD Programmable Field under z/OS?)
On Fri, 19 Mar 2021 14:43:05 +0800, Timothy Sipples wrote: >... >Paul Gilmartin wrote: >>The latter suggests that a pseudo RNG is periodically reseeded >>by the TRNG > >Yes, that's right. CPACF on the IBM z14 and LinuxONE II models, and >higher, have this feature. If you try to use the TRNG for every random >number request it's really slow, but fortunately that's not required to >achieve the desired, certified outcome. Seeding is rather important, >though, and that's why they're there. > Thanks. UNIX has long had /dev/random, a TRNG (subject to hardware availability) and /dev/urandom, a seeded PRNG. For a while I had a Solaris tower under my desk. The perceptible difference was that "cat /dev/random >/dev/null" caused the fan to speed up audibly; "cat /dev/urandom >/dev/null" was silent. And: https://en.wikipedia.org/wiki/Lavarand -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
Thanks Ed, I hadn't actually looked at the RNG capabilities in CPACF in recent times. From an initial once-over of the TRNG capability described in the latest PoOP, it may be a better source of data than STCKE for my application. I will need to make some performance measurements to make sure I am not slowing the application process flow too much. The COBOL UUID4 function may be the "future state" version for my application requirements, once we are up to date enough to use it. That will need some performance measuring too once we are there. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Ed Jaffe Sent: Thursday, March 18, 2021 10:06 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Contents of TOD Programmable Field under z/OS? On 3/18/2021 6:38 PM, Paul Gilmartin wrote: > > Using clock values as a source of entropy is discouraged. If a > (fe)malefactor can make a good guess at an interval during which the > clock is sampled there's little entropy available. IBM Z was recently enhanced with a true random source in CPACF. For all the many decades before that, all "random" numbers on the mainframe were actually pseudo-random... -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
I actually do not care what the value is, so long as it is guaranteed to be unique. I am curious about the technique and value used, but I actually don't *need* my curiosity satisfied. Documentation of a guarantee of uniqueness is all I think a management review would require, and in truth that is all that I would actually require because the actual value isn’t relevant to the need. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Thursday, March 18, 2021 9:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Contents of TOD Programmable Field under z/OS? On Thu, 18 Mar 2021 23:33:25 +, Farley, Peter x23353 wrote: >Peter, > >I must disagree that it is not a programming interface. The problem-state >instruction STCKE returns its value and the field is clearly defined in PoOP, >so problem-state users deserve to know how the contents are set by the only >program authorized to set it, the operating system. > >The particular application here involves generating unique application-related >values. I can also see its application to entropy-gathering routines >determining a unique random seed for statistical purposes. > >There are probably other uses I haven't imagined. > Uncharacteristically, I'll agree with Peter R. here (mostly). I said earlier: A possible answer is that it's release-dependent, subject to change, and as long as the [uniqueness] constraint is met IBM chooses not to document it in order to retain flexibility for future releases. My "mostly" is that IBM might provide in a software publication assurance that the OS sets bits 112-127 to values that guarantee uniqueness with a stated scope. Using clock values as a source of entropy is discouraged. If a (fe)malefactor can make a good guess at an interval during which the clock is sampled there's little entropy available. As for "unique application-related values" and probable "other uses", present a business case. But the PoOps does not disdain software topics. It contains tables of a few dozen entries mapping TOD values to UTC. These depend on a site's choice of TOD epoch (some still use local) and leap second conventions. (We abandoned leap seconds for timestamp consistency across program products.) Those tables might more properly appear in a software publication, perhaps in the description of the TIME and STCKCONV macros. >-Original Message- >From: Peter Relson >Sent: Thursday, March 18, 2021 7:14 PM > >It should be expected that the principles of operation not have any >information about what data is placed there, as it is specifically defined to >be set by a program to whatever that program wants it to be. > >I'll bite: why would we want to document how the operating system sets this? >It is not a programming interface. >In what way would having this information help diagnosis (that being the only >other reason I could think of)? -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
Ed Jaffe wrote: >IBM Z was recently enhanced with a true random source in CPACF. >For all the many decades before that, all "random" numbers on the >mainframe were actually pseudo-random... The IBM Crypto Express features have had TRNGs aboard for many years (and still do). This is a fairly complex topic if you get into the details, and TRNGs are not my speciality. However, my understanding is that if you have a Crypto Express domain configured to a LPAR (in CCA mode I believe) then it automatically contributes to entropy for seeding. Having a TRNG (a.k.a. NDRNG) on chip with CPACF means you get an entropy boost even without a Crypto Express domain. You should still get Crypto Express features, assuming you can get them in your country. They're more important than ever. Paul Gilmartin wrote: >The latter suggests that a pseudo RNG is periodically reseeded >by the TRNG Yes, that's right. CPACF on the IBM z14 and LinuxONE II models, and higher, have this feature. If you try to use the TRNG for every random number request it's really slow, but fortunately that's not required to achieve the desired, certified outcome. Seeding is rather important, though, and that's why they're there. - - - - - - - - - - Timothy Sipples I.T. Architect Executive Digital Asset & Other Industry Solutions IBM Z & LinuxONE - - - - - - - - - - E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
On Thu, 18 Mar 2021 19:06:07 -0700, Ed Jaffe wrote: >> >> Using clock values as a source of entropy is discouraged. If a >> (fe)malefactor can make a good guess at an interval during which >> the clock is sampled there's little entropy available. > >IBM Z was recently enhanced with a true random source in CPACF. > Has IBM published the technology, perhaps in a Redbook? A quick scan of https://www.ibm.com/downloads/cas/2MKRAY3Y is uninformative. Little more at: https://www.ibm.com/support/knowledgecenter/SSB23S_1.1.0.2020/gtps7/hwrandomnum.html The latter suggests that a pseudo RNG is periodically reseeded by the TRNG >For all the many decades before that, all "random" numbers on the >mainframe were actually pseudo-random... > I'm imagining a beam splitter and a pair of detectors. Ah!: https://dl.acm.org/doi/10.1147/JRD.2013.2279599 -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
On 3/18/2021 6:38 PM, Paul Gilmartin wrote: Using clock values as a source of entropy is discouraged. If a (fe)malefactor can make a good guess at an interval during which the clock is sampled there's little entropy available. IBM Z was recently enhanced with a true random source in CPACF. For all the many decades before that, all "random" numbers on the mainframe were actually pseudo-random... -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
On Thu, 18 Mar 2021 23:33:25 +, Farley, Peter x23353 wrote: >Peter, > >I must disagree that it is not a programming interface. The problem-state >instruction STCKE returns its value and the field is clearly defined in PoOP, >so problem-state users deserve to know how the contents are set by the only >program authorized to set it, the operating system. > >The particular application here involves generating unique application-related >values. I can also see its application to entropy-gathering routines >determining a unique random seed for statistical purposes. > >There are probably other uses I haven't imagined. > Uncharacteristically, I'll agree with Peter R. here (mostly). I said earlier: A possible answer is that it's release-dependent, subject to change, and as long as the [uniqueness] constraint is met IBM chooses not to document it in order to retain flexibility for future releases. My "mostly" is that IBM might provide in a software publication assurance that the OS sets bits 112-127 to values that guarantee uniqueness with a stated scope. Using clock values as a source of entropy is discouraged. If a (fe)malefactor can make a good guess at an interval during which the clock is sampled there's little entropy available. As for "unique application-related values" and probable "other uses", present a business case. But the PoOps does not disdain software topics. It contains tables of a few dozen entries mapping TOD values to UTC. These depend on a site's choice of TOD epoch (some still use local) and leap second conventions. (We abandoned leap seconds for timestamp consistency across program products.) Those tables might more properly appear in a software publication, perhaps in the description of the TIME and STCKCONV macros. >-Original Message- >From: Peter Relson >Sent: Thursday, March 18, 2021 7:14 PM > >It should be expected that the principles of operation not have any >information about what data is placed there, as it is specifically defined to >be set by a program to whatever that program wants it to be. > >I'll bite: why would we want to document how the operating system sets this? >It is not a programming interface. >In what way would having this information help diagnosis (that being the only >other reason I could think of)? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
Peter, I must disagree that it is not a programming interface. The problem-state instruction STCKE returns its value and the field is clearly defined in PoOP, so problem-state users deserve to know how the contents are set by the only program authorized to set it, the operating system. The particular application here involves generating unique application-related values. I can also see its application to entropy-gathering routines determining a unique random seed for statistical purposes. There are probably other uses I haven't imagined. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Relson Sent: Thursday, March 18, 2021 7:14 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Contents of TOD Programmable Field under z/OS? It should be expected that the principles of operation not have any information about what data is placed there, as it is specifically defined to be set by a program to whatever that program wants it to be. I'll bite: why would we want to document how the operating system sets this? It is not a programming interface. In what way would having this information help diagnosis (that being the only other reason I could think of)? Peter Relson z/OS Core Technology Design -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
It should be expected that the principles of operation not have any information about what data is placed there, as it is specifically defined to be set by a program to whatever that program wants it to be. I'll bite: why would we want to document how the operating system sets this? It is not a programming interface. In what way would having this information help diagnosis (that being the only other reason I could think of)? Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
On Thu, 18 Mar 2021 14:42:21 -0500, Salva Carrasco wrote: > >CPC 1 & 2 are in different rooms. I think Einstein's relativity effects will >be greater than TOD last bits counter. > If they're on different floors, does STP account for gravitational redshift? I suppose that's just folded in with differential clock drift. And software must account for transactions reported many kilometers apart. Or not: https://www.youtube.com/watch?v=ibQmtYrTEDQ -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
Paul, CPC 1 & 2 are in different rooms. I think Einstein's relativity effects will be greater than TOD last bits counter. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
Looking an that, i'm assuming it assigns a sequential number to an LPAR within a connected group of z processors. I'm assuming when you connect two processors already up it will reassign the sequence number? . On Thu, Mar 18, 2021 at 1:33 PM Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > > On Thu, 18 Mar 2021 11:39:06 -0500, Salva Carrasco wrote: > > >Peter, from my Sysplexex (two CPC, two Sysplexes): > > > >Sysplex 1: > >LPAR1 - CPC 1 - 00D96E2471DF1F55880008040001 > >LPAR2 - CPC 1 - 00D96E2543F30EBBA20008040003 > >LPAR1 - CPC 2 - 00D96E24D3FB3288420008040002 > >LPAR2 - CPC 2 - 00D96E25612D8B3846000804 > >... > So uniqueness is guaranteed. Is monotonicity likewise guaranteed? > > Suppose a task on LPAR1 CPC 2 does STCKE, then a task on LPAR 1 CPC 1 > does STCKE so soon afterward that bits 0-111 are identical. The value > stored first appears greater because of bits 112-127. But is there any > sequence of instructions that could detect that prochronism? > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
On Thu, 18 Mar 2021 11:39:06 -0500, Salva Carrasco wrote: >Peter, from my Sysplexex (two CPC, two Sysplexes): > >Sysplex 1: >LPAR1 - CPC 1 - 00D96E2471DF1F55880008040001 >LPAR2 - CPC 1 - 00D96E2543F30EBBA20008040003 >LPAR1 - CPC 2 - 00D96E24D3FB3288420008040002 >LPAR2 - CPC 2 - 00D96E25612D8B3846000804 >... So uniqueness is guaranteed. Is monotonicity likewise guaranteed? Suppose a task on LPAR1 CPC 2 does STCKE, then a task on LPAR 1 CPC 1 does STCKE so soon afterward that bits 0-111 are identical. The value stored first appears greater because of bits 112-127. But is there any sequence of instructions that could detect that prochronism? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
Thank you Salva. We have only one Sysplex here (though we do have 2 JESPLEX's for historical reasons), and I have confirmed that the two LPAR's I have access to run code on have different last byte values (02 and 08) so I am reasonably confident I can use that byte for LPAR uniqueness here. I would still like to see any available documentation of how z/OS sets that value (if any such documentation exists) so I have backup in case management asks. Peter Relson or Jim Mulder, can either of you say whether there is any available documentation of this TOD field setting? Peter -Original Message- From: Salva Carrasco Sent: Thursday, March 18, 2021 12:39 PM To: IBM-MAIN@LISTSERV.UA.EDU; Farley, Peter x23353 Subject: Re: Contents of TOD Programmable Field under z/OS? Peter, from my Sysplexex (two CPC, two Sysplexes): Sysplex 1: LPAR1 - CPC 1 - 00D96E2471DF1F55880008040001 LPAR2 - CPC 1 - 00D96E2543F30EBBA20008040003 LPAR1 - CPC 2 - 00D96E24D3FB3288420008040002 LPAR2 - CPC 2 - 00D96E25612D8B3846000804 Sysplex2: LPAR3 - CPC 1 - 00D96E25A47E64BAC801 LPAR4 - CPC 2 - 00D96E25CB7002F3C40008080002 Last byte match the first byte from SYSTEM NUMBER output of DISPLAY XCF,SYSPLEX,ALL. No idea about bytes 29, 30 & 31. Regards, salva. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
Peter, from my Sysplexex (two CPC, two Sysplexes): Sysplex 1: LPAR1 - CPC 1 - 00D96E2471DF1F55880008040001 LPAR2 - CPC 1 - 00D96E2543F30EBBA20008040003 LPAR1 - CPC 2 - 00D96E24D3FB3288420008040002 LPAR2 - CPC 2 - 00D96E25612D8B3846000804 Sysplex2: LPAR3 - CPC 1 - 00D96E25A47E64BAC801 LPAR4 - CPC 2 - 00D96E25CB7002F3C40008080002 Last byte match the first byte from SYSTEM NUMBER output of DISPLAY XCF,SYSPLEX,ALL. No idea about bytes 29, 30 & 31. Regards, salva. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
On Thu, 18 Mar 2021 08:47:58 +1100, Attila Fogarasi wrote: >It is documented in Pops under the SCKPF instruction (which is where I >would expect). For z/OS it is unique sysplex-wide (i.e. in the scope where >zos can co-ordinate setting the prefix value). Sole purpose is to resolve >timestamp collisions. > Yes, and further: Programming Note: The values in the TOD programmable registers of a configuration should be the same and should be unique within a multiple-configuration system. But the question remains, how does the OS determine the values used? A possible answer is that it's release-dependent, subject to change, and as long as the constraint above is met IBM chooses not to document it in order to retain flexibility for future releases. Wisely, bits 32-47 "must be zero". This effectively reserves them for use in future models (for flags?) >On Thu, Mar 18, 2021 at 2:19 AM Farley, Peter wrote: > >> I have recently seen a comment in a prior co-worker's assembler code which >> used STCKE to retrieve the TOD "Programmable Field" contents: >> >> "The Field contains a value, assigned by z/OS, which uniquely identifies a >> current LPAR in the SYSPLEX of machines." >> >> Is this a true statement, and if so is it documented anywhere? >> >> If true, is the value unique to the CPU or to the LPAR or to the CPC or . >> . . ? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
PoOP only says this under SCKPF: Programming Note: The values in the TOD programmable registers of a configuration should be the same and should be unique within a multiple-configuration system. It says nothing about what value z/OS puts into the field, only that t "should be unique" (only "should", not "must"). I still have the question: Is the value populated by z/OS into that field documented anywhere? Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Attila Fogarasi Sent: Wednesday, March 17, 2021 5:48 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Contents of TOD Programmable Field under z/OS? It is documented in Pops under the SCKPF instruction (which is where I would expect). For z/OS it is unique sysplex-wide (i.e. in the scope where zos can co-ordinate setting the prefix value). Sole purpose is to resolve timestamp collisions. On Thu, Mar 18, 2021 at 2:19 AM Farley, Peter x23353 < 031df298a9da-dmarc-requ...@listserv.ua.edu> wrote: > I have recently seen a comment in a prior co-worker's assembler code > which used STCKE to retrieve the TOD "Programmable Field" contents: > > "The Field contains a value, assigned by z/OS, which uniquely > identifies a current LPAR in the SYSPLEX of machines." > > Is this a true statement, and if so is it documented anywhere? > > If true, is the value unique to the CPU or to the LPAR or to the CPC or . > . . ? > > Peter -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
It is documented in Pops under the SCKPF instruction (which is where I would expect). For z/OS it is unique sysplex-wide (i.e. in the scope where zos can co-ordinate setting the prefix value). Sole purpose is to resolve timestamp collisions. On Thu, Mar 18, 2021 at 2:19 AM Farley, Peter x23353 < 031df298a9da-dmarc-requ...@listserv.ua.edu> wrote: > I have recently seen a comment in a prior co-worker's assembler code which > used STCKE to retrieve the TOD "Programmable Field" contents: > > "The Field contains a value, assigned by z/OS, which uniquely identifies a > current LPAR in the SYSPLEX of machines." > > Is this a true statement, and if so is it documented anywhere? > > If true, is the value unique to the CPU or to the LPAR or to the CPC or . > . . ? > > Peter > > This message and any attachments are intended only for the use of the > addressee and may contain information that is privileged and confidential. > If the reader of the message is not the intended recipient or an authorized > representative of the intended recipient, you are hereby notified that any > dissemination of this communication is strictly prohibited. If you have > received this communication in error, please notify us immediately by > e-mail and delete the message and any attachments from your system. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
PoOP (-12 edition) states on page 4-47: For certain instructions, the TOD clock is considered to be extended to the left by an 8-bit epoch index. In a multiprocessing configuration, a single epoch index is shared by all CPUs. When the multiple-epoch facility is not installed in the configuration, the epoch index contains zeros when the TOD clock has not wrapped around to zero; when the TOD clock has wrapped around to zeros, it is unpredictable whether or not the epoch index contains zeros. When the multiple- epoch facility is installed in the configuration, the epoch index extends the capacity of the monotonic sequence of clock values to approximately 36,534 years. But that is not the location I am asking about. I am asking about the LOW-order two bytes (the "Programmable Field"). Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Wednesday, March 17, 2021 3:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Contents of TOD Programmable Field under z/OS? EXTERNAL EMAIL On Wed, 17 Mar 2021 14:53:36 -0400, Brian Chapman wrote: >I may need wrong, but I seem to remember reading that the 12 bit lower >order value had some relation to the processor ID. This ensured the >STCK value would be unique across the sysplex. > The patent is no help: https://urldefense.com/v3/__https://patents.justia.com/patent/20030101365__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!agRiorhCck5mAi2lTCG_ERgnTSnUGJMI0Sc4PUakKoE0EsD8S_V33ke2e0_B4pX9NIMoiw$ It never states, but one might infer that the high-order byte of ETOD might be incremented (by software?) when the clock wraps. >On Wed, Mar 17, 2021, 1:55 PM Farley, Peter x23353 wrote: > >> But is it documented anywhere? PoOP is silent on the value of the field. >> RCF needed. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
On Wed, 17 Mar 2021 14:53:36 -0400, Brian Chapman wrote: >I may need wrong, but I seem to remember reading that the 12 bit lower >order value had some relation to the processor ID. This ensured the STCK >value would be unique across the sysplex. > The patent is no help: https://patents.justia.com/patent/20030101365 It never states, but one might infer that the high-order byte of ETOD might be incremented (by software?) when the clock wraps. >On Wed, Mar 17, 2021, 1:55 PM Farley, Peter x23353 wrote: > >> But is it documented anywhere? PoOP is silent on the value of the field. >> RCF needed. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
I may need wrong, but I seem to remember reading that the 12 bit lower order value had some relation to the processor ID. This ensured the STCK value would be unique across the sysplex. On Wed, Mar 17, 2021, 1:55 PM Farley, Peter x23353 < 031df298a9da-dmarc-requ...@listserv.ua.edu> wrote: > But is it documented anywhere? PoOP is silent on the value of the field. > > Peter > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Salva Carrasco > Sent: Wednesday, March 17, 2021 12:59 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Contents of TOD Programmable Field under z/OS? > > Afaik unique to the LPAR & Sysplex. > > -- > > This message and any attachments are intended only for the use of the > addressee and may contain information that is privileged and confidential. > If the reader of the message is not the intended recipient or an authorized > representative of the intended recipient, you are hereby notified that any > dissemination of this communication is strictly prohibited. If you have > received this communication in error, please notify us immediately by > e-mail and delete the message and any attachments from your system. > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
On Wed, 17 Mar 2021 17:55:12 +, Farley, Peter x23353 wrote: >But is it documented anywhere? PoOP is silent on the value of the field. > I had the belief that it comes from PARMLIB. But I can't find it in CLOCKxx. RCF? Uniqueness and the 16-bit field impose a limit of 64 KiLPARs. >-Original Message- >From: Salva Carrasco >Sent: Wednesday, March 17, 2021 12:59 PM > >Afaik unique to the LPAR & Sysplex. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
But is it documented anywhere? PoOP is silent on the value of the field. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Salva Carrasco Sent: Wednesday, March 17, 2021 12:59 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Contents of TOD Programmable Field under z/OS? Afaik unique to the LPAR & Sysplex. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Contents of TOD Programmable Field under z/OS?
Afaik unique to the LPAR & Sysplex. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Contents of TOD Programmable Field under z/OS?
I have recently seen a comment in a prior co-worker's assembler code which used STCKE to retrieve the TOD "Programmable Field" contents: "The Field contains a value, assigned by z/OS, which uniquely identifies a current LPAR in the SYSPLEX of machines." Is this a true statement, and if so is it documented anywhere? If true, is the value unique to the CPU or to the LPAR or to the CPC or . . . ? Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
