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 <IBM-MAIN@LISTSERV.UA.EDU> 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 +0000, 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