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
