042 the
>next epoch of B'01' currently used to represent 1936-1971 and might
>have some data to be flagged.
>
Why so complicated? I had imagined the Epoch Index as simply an
8-bit leftward extension of the TOD, extending the range from
142.713391 to approximately 36,534 years.
What's the
to be flagged.
On Wed, Jun 12, 2024 at 6:56 AM Peter Relson wrote:
>
>
> Am I correct in understanding that on current hardware an overflow from the
> TOD
> will be carried into the Epoch Index, but only once?
>
> No, that is not correct. The Epoch Index gets incremented upon
On Wed, 12 Jun 2024 11:55:57 +, Peter Relson wrote:
>
>
>Am I correct in understanding that the Clock Comparator remains in 64-bit
>TOD format? How will intervals spanning that time in 2042 be handled?
>
>Yes, it is true. The short answer to the second question is "correctly".
>As a hint,
Am I correct in understanding that on current hardware an overflow from the TOD
will be carried into the Epoch Index, but only once?
No, that is not correct. The Epoch Index gets incremented upon the
wrap/overflow, for as many epochs as happen.
Am I correct in understanding that the Clock
On Tue, 11 Jun 2024 17:34:15 +, Jim Mulder wrote:
> z/OS 3.1 does not support testing with dates beyond 09/17/2042.
>
Am I correct in understanding that on current hardware an overflow from the TOD
will be carried into the Epoch Index, but only once?
Am I correct in underst
z/OS 3.1 does not support testing with dates beyond 09/17/2042.
Jim Mulder
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Paul Schuster
Sent: Tuesday, June 11, 2024 1:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Epoch Index
So, as of z/os 3.1, there does
So, as of z/os 3.1, there does not seem to be a way to test with dates beyond
09/17/2042? A “R 00,DATE=2042.260 “ works, but a “R 00,DATE=2042.261”
generates a “IEE306I RPLY HAS INVALID NUMERICS” message.
Or am I missing something obvious?
Thank you.
>A programmer sets comparator ...
I hope that, at least for z/OS, only z/OS BCP programs are doing so.
Peter Relson
z/OS Core Technology Design
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to
On 2021-03-21, at 07:52:27, Peter Relson wrote:
>
> The software will not have to do anything in order to get the epoch index
> to increase to 1 in September 2042. ...
>
Thanks. I saw that cleearly in the PoOps.
> The clock comparator remains an 8 byte entity. But the
The software will not have to do anything in order to get the epoch index
to increase to 1 in September 2042. It will happen when the clock wraps,
as long as you're running on a machine that supports the multiple epoch
facility (maybe the OS has to enable something, but that would be about
PoOps "Figure 4-12. Format of the TOD Clock, ..." shows that SCK does
not affect the Epoch Index. "Additionally, the PTFF instruction [*may*]
manipulate the TOD clock and epoch index, ..." "may" or perhaps not?
I tired of searching before I found particula
11 matches
Mail list logo
