On Sat, 20 Mar 2021 04:54:34 +0000, 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
