On 2014-06-23, at 05:29, Hardee, Chuck wrote:
> John, as other have said, very well put, thanks!
> However, I do have one question.
> Why not use the OFFSET= parameter of the CONVTOD macro to add the OP's time
> increment to the TOD value they have?
> Why do it manually?
>
> (More a curiosity than anything else.)
>
(I, too, needed to RTRM.)
http://pic.dhe.ibm.com/infocenter/zos/v2r1/topic/com.ibm.zos.v2r1.ieaa700/iea3a7_Description4.htm
,OFFSET=offset value
Specifies a 4-byte storage area containing a packed decimal number of the
form 000HHMMX, where X is the sign (D for a negative number, F for a
positive
number). The offset value is added to the input time. The offset value is
generally the difference between Greenwich Mean Time and local time but it
can be any desired value. The default value is X'0000000F'.
Apparently the granularity is one minute, not meeting the OP's requirement
of 30 seconds.
The "HHMM" notation strains my notion of "packed decimal number". Looks
more like bi-sexagesimal.
On 2014-06-22, at 19:48, John Gilmore wrote:
> I 'believe' in leap seconds in the senses that 1) they are present in
> UTC values and 2) their use is effective in reducing precession.
>
> My belief [or not] in leap seconds is, however, moot here. Both
> STCKCONV and CONVTOD reflect leap seconds in their algorithms,
> appropriately albeit clumsily.
>
By "doesn't believe", I recall you've taken offense at the notation
"23:59:60"; IIRC it strains your notion of congruence. But what form
would you prefer?:
23:59:60?
00:00:-1 of the following day?
eschew any representation of leap second ("don't believe")
other (specify)?
But vide infra.
z/Architecture Principles of Operation
IBMr
SA22-7832-09
...
TOD Programmable Register
...
8. The following chart shows the TOD clock setting for 00:00:00 (0 am),
UTC time, for several dates: January 1, 1900, January 1, 1972, and
for that instant in time just after each of the 25 leap seconds that
have occurred through July, 2012. Each of these leap seconds was
inserted in the UTC time scale beginning at 23:59:60 UTC of the day
previous to the one listed and ending at 00:00:00 UTC of the day listed.
...
1990-1-1 15 A171 7D06 3E1C 0000
Our site has disabled leap seconds -- incompatibility with vendor software;
one of the vendors being IBM. Would anyone at a site with leap seconds
enabled volunteer to test STCKCONV with the cited value, A171 7D06 3E1C 0000
to verify that "STCKCONV and CONVTOD reflect leap seconds in their algorithms,
appropriately albeit clumsily"? I.e. that:
1990-1-1 00:00:00 <--> A171 7D06 3E1C 0000
(Yes, I'm still seething that my RFC for additional documentation was
rejected.)
-- gil
