On 2013-04-19, at 05:34, Peter Relson wrote:
>
> The value from STCK is neither GMT nor LOCAL. If you want to convert it,
> then you are always welcome to do so (and some services might even help
> you)..
>
Which services?
On 2013-04-20, at 12:39, Peter Relson wrote:
>> I find George Kozakos's answer more satisfactory than yours.
>
> You might have found George's response "more satisfactory", but it was
> incorrect in a subtle way.
>
> George wrote
>> It's neither. It's the STCK time where
>> UTC = STCK - CVTLSO
>> LOCAL = STCK - CVTLSO + CVTLDTO
>
> What he wrote is largely true about a time that is the result of the
> STCK(E) instruction in the typical case (although customers are not forced
> to be typical). More, there is no necessity that the input to STCKCONV
> have been created by such an instruction (let alone by an instruction that
> was recently executed). Only the creator of a time value knows its format
> and its intent. A given STCK-format value has a deterministic
> representation in date/time format. That is all that can be said. Whether
> it is local, UTC or GMT or came from the STCK(E) instruction is a fact
> unknown to the system and up to the application to decide and document to
> the extent its users need to know.
>
You're in an ivory tower. Practical programmers have less abstract
needs.
> For what it's worth, and I might be wrong about this, I thought that the
> clock was typically recommended to be set to UTC.
>
No. The P[ro]Ops recommends that the TOD clock run at the rate of TAI
with an origin of 1900-01-01 00:00:10.
> And by subtracting CVTLSO from the STCK value you get to GMT, not to UTC
> (UTC differing from GMT by leap seconds).
>
You're confusing UTC with TAI. UTC is adjusted by adding (or
subtracting) leap seconds to remain within 0.9 seconds of GMT
(or very nearly UT1).
http://hpiers.obspm.fr/eop-pc/index.php?index=leapsecond&lang=en
> And you get to LOCAL by taking GMT and subtracting CVTLDTO.
>
>> There's a question here that can reasonably be asked,
>> and he provided a clear answer.
>
> I disagree. Because George did not answer a question that can be answered
> by STCKCONV. The documentation says "The STCKCONV macro converts an input
> time-of-day (TOD) clock value to time of day and date, and returns the
> converted values to the caller in the format requested. " This is correct
> and is complete and is all that the service can say.
>
Reading the P[ro]Ops as Steve Thompson suggested, I can infer some
history (only a little reading between the lines).
Prior to 1972, the TOD clock was adjusted to run at a rate determined
by the rotation of the earth, with origin at GMT 1900-01-01 00:00:00.
So some simple congruence arithmetic sufficed to convert a TOD clock
reading to the corresponding GMT, within the precision of the output
format. I believe this was the original objective and implementation
of STCKCONV.
In 1972, UTC was devised, to run at the clock frequency of TAI, but
with leap seconds inserted to keep UTC close to UT1/GMT. IBM chose
then to switch to running the TOD clock at the more accurate TAI
rate rather than the UT1 rate. However, at that time UT1/GMT was
already 10 seconds behind TAI. Rather than introduce a discontinuity
in the TOD clock, MVS splined the two clocks together by redefining
the origin of TOD to be TAI 1900-01-01 00:00:10.
The P[ro]Ops says (quoting again):
z/Architecture Principles of Operation
SA22-7832-08
Time-of-Day Clock
...
5. In converting to or from the current date or time,
the programming support must take into account that
“leap seconds” have been inserted or deleted because
of time-correction standards.
But the developers of STCKCONV shirked the word "must", abandoned
its original (my inference) objective and retained the simple
(now too simple) congruence formula. As a result, the present
behavior of STCKCONV is:
When the input (E)TOD value has been obtained from a reading
of the TOD clock set as recommended by IBM,
o If the STCK value is from prior to 1972, the output is GMT
within the precision of the output format.
o If the STCK value is from 1972 or later, the output may
be regarded either as TAI - 10 seconds or, equivalently,
as UTC + (TAI-UTC-10 seconds).
http://hpiers.obspm.fr/eop-pc/index.php?index=TAI-UTC_tab&lang=en
(or from Table in the Principles of Operation).
Those are the facts as I understand them. The description of
STCKCONV ought to state them as they concern the most practical
use of STCKCONV, namely to convert a value obtained from STCK
to GMT and not require the programmer to research the P[ro]Ps,
until and unless STCKCONV (probably optionally) accepts the
instructions in the P[ro]Ops (I stress the word "must" again)
and applies leap second corrections.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
