On Jan 9, 2012, at 15:37, John Gilmore wrote:
>
> Numbering the BYTES of an STCKE value in zero-origin fashion from left
> to right, bytes 14 and 15 contain the programmable-field value. Do
> not include it in your calculations. Do include byte 0; after
> 23:58:43 on 2042 September 17 you will need it.
>
The PoOp says:
14. At some time in the future, new models will use a carry
from bit position 0 of the TOD clock to increment an
additional eight-bit binary counter. STORE CLOCK EXTENDED
will store the contents of this counter in byte position
0 of its storage operand.
Strange wording. I wonder why it doesn't just say the TOD
clock will be extended leftward to 112 bits rather than 104
and not describe it as "an additional eight-bit binary
counter"?
Alas, STCKCONV doesn't anticipate this. IIRC, I tried it a while
ago; it simply ignores byte 0. It would be better if it returned
error status indicating "Invalid STCKE Value" or "Unimplemented
Feature" until the conversion became available. (Or just
anticipate the feature and include byte 0 in the conversion.)
But I have an Immodest Proposal. (I'll not leave that platform
to John M., exclusively.) Define the future extension of the
TOD clock as a signed binary 112-bit (111+sign) value. Rationale:
given that some contracts and treaties entered in the 19th
century are likely still in effect, there would be more utility
in supporting a STCKE-compatible representation of dates in the
19th century or somewhat before than of dates in the 204th
century and later.
-- gil
