Epoch Index
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 particulars of PTFF.
Is it anticipated that circa 2043 an updated OS will use a combination
of SCK and PTFF to set TOD and Epoch Index.
Does the Clock Comparator account for Epoch Index? What will happen
on that critical date circa 2043 if a programmer does a STIMER for
several hours?
• When the multiple-epoch facility is installed in the configuration,
the carry causes the epoch index to be incremented by 1. Any carry
propagated out of the leftmost bit position of the epoch index is ignored.
I'll conclude that if an inquisitive and privileged programmer sets
the Epoch Index and TOD to x'7F ..." and waits, the pair will
wrap to x'80 "
I've long felt that the Epoch Index should be considered signed. It's
more useful to be able to represent times in the 19th Century than
in the 300th.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Epoch Index
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 it). Of course a lot of OS changes need to be in place when that does occur. The clock comparator remains an 8 byte entity. But the OS will be able to indicate that the CC is to be treated as signed, so that _ will be "later" than (the negative) _. That exploitation of the multiple epoch facility does require OS action. And probably requires a converse action every 70 years or so when the high bit of the TOD clock changes. In the future, one would expect a z/OS release to document that it is OK to set the clock so that it can cross the 2042 epoch end (or be later than the epoch end), and similarly the 2038 time related to the z/OS Unix clock wrap point. Until such a time, do not do that. There will be no expectation initially that you can work with times beyond the 2nd epoch. There is likely no expectation of results if a system stays up for over 70 years. And it will be the case that you are expected not to have data that is over 140-ish years old when you need to work with an 8-byte timestamp (many cases will use a windowing approach, not using a 16-byte timestamp). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Epoch Index
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 OS will be able to > indicate that the CC is to be treated as signed, so that _ > will be "later" than (the negative) _. That exploitation > of the multiple epoch facility does require OS action. And probably > requires a converse action every 70 years or so when the high bit of the > TOD clock changes. > I had envisioned a ±70-year window implemented by continually performing a Subtract Logical TOD - Comparator and testing the sign. The behavior would be more continuous, not requiring "action every 70 years or so". Any implementation is likely to have hazards when: o A programmer sets comparator to 0 to indicate "immediately". o A programmer sets comparator to maximum to indicate "never". o An expiry time is set very near maximum and the CPU is not dispatchable at that time. There is a legend (reported here a few years ago?) of a program that used a value of decimal one billion to indicate "never" and looped when that time occurred. Thanks again, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Epoch Index
>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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Epoch Index
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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Epoch Index
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 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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Epoch Index
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 understanding that the Clock Comparator remains in 64-bit TOD format? How will intervals spanning that time in 2042 be handled? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Epoch Index
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 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, try doing 64-bit arithmetic that subtracts a before-wrap 8-byte TOD value from an after-wrap 8-byte TOD value and see what you get. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Epoch Index
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, try doing 64-bit arithmetic that subtracts a before-wrap 8-byte TOD >value from an after-wrap 8-byte TOD value and see what you get. > Thanks. I can do that mentally. Suppose Subtract Logical or ignore overflow then then test only the sign bit. That amounts to a 142-year window centered on the current time. Rely on SL, not CL. I had wondered whether a programmer who naively loads the comparator with x'' expecting no expiration before 2042, or with 0 expecting immediate expiration would be rudely surprised. The answer is, "Don't do that!" -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Epoch Index
If I remember correctly, the timestamp runs from 1900 to 2042, checking 1 high bit gives you 2 X 71 year epochs, 2 high bits gives 4 X 35.5 year epochs, 3 high bits gives 8 X 15.75 year epochs, 4 high bits 16 X 7.875 year epochs. Suggest checking 2 high bits, treating current and past 2 epochs (71- 106.5 years) as valid, and the next epoch as past data that needs to be cleared before reuse. From now to 2042, the future epoch of b'00'did represent 1900-1935 so no past data, but starting in 2042 the next epoch of B'01' currently used to represent 1936-1971 and might have some data 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 the > wrap/overflow, for as many epochs as happen. > > > 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, try doing 64-bit arithmetic that subtracts a before-wrap 8-byte > TOD value from an after-wrap 8-byte TOD value and see what you get. > > Peter Relson > z/OS Core Technology Design > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Epoch Index
On Wed, 12 Jun 2024 11:34:15 -0500, Mike Schwab wrote: >If I remember correctly, the timestamp runs from 1900 to 2042, >checking 1 high bit gives you 2 X 71 year epochs, 2 high bits gives 4 >X 35.5 year epochs, 3 high bits gives 8 X 15.75 year epochs, 4 high >bits 16 X 7.875 year epochs. > >Suggest checking 2 high bits, treating current and past 2 epochs (71- >106.5 years) as valid, and the next epoch as past data that needs to >be cleared before reuse. From now to 2042, the future epoch of >b'00'did represent 1900-1935 so no past data, but starting in 2042 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 significance of 35 years, other than that it's 1/4 of 142? I was dismayed that the ETOD was not defined as signed. I feel that dates in the 19th Century and even back to the 1st are more relevant than the 380th. Format conversion through that range is hardly meaningful. It would be overwhelmed by ΔT, hours in historic times: <https://en.wikipedia.org/wiki/%CE%94T_(timekeeping)>. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Epoch Index
On 6/11/2024 10:12 AM, Paul Schuster wrote: 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. Years ago, one of our programmers fat-fingered a ZAP that accidentally turned an MVC into an SCK (SET CLOCK) of =FD'-1'. It took down z/OS. It kept crashing just a few minutes after everything was brought back up. We didn't even have time to get into IPCS to analyze the stand-alone dump. This happened over and over again until 5 pm when, frustrated with our poorly-performing system, he finally went home for the day. It was (SVO) "fun" trying to figure out what happened... 😕 -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Epoch Index
On Tue, 25 Jun 2024 19:09:53 -0700, Ed Jaffe wrote: >... >Years ago, one of our programmers fat-fingered a ZAP that accidentally >turned an MVC into an SCK (SET CLOCK) of =FD'-1'. It took down z/OS. It >kept crashing just a few minutes after everything was brought back up. > Eerily reminiscent of a Red Alert IBM issued a couple years ago. A macro, customer facing therefore hard to change, was doing a STCK to a wild address. When a certain bit in the TOD changed, IPL cod which tests that bit with no effect other than to crash when it had the wrong value would make the next IPL impossible. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Epoch Index
Gil wrote Eerily reminiscent of a Red Alert IBM issued a couple years ago. A macro, customer facing therefore hard to change, was doing a STCK to a wild address. When a certain bit in the TOD changed, IPL cod which tests that bit with no effect other than to crash when it had the wrong value would make the next IPL impossible. That seems unlikely, and almost inconceivable unless you IPL without "clear" (aside from if the corrupted storage got written to a data set that was read upon re-IPL). Might you have any details? I certainly understand relatively unpredictable side effects within the current IPL, Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Epoch Index
I haven't seen that Red Alert but my guess is that it is STP related; STP provides that non-z/OS persistent data store that can cross IPLs. I know that an Epoch change in STP can prevent zos joining sysplex and requires sysplex-wide re-ipl, for example -- one of the rather rare sysplex-wide failures, though to zos's credit even that doesn't cause an outage. STP also has options of how Epoch changes are (mis)managed. Always wondered about STP design, but I don't know the constraints they had, it never seemed up to the standards of the rest of the system. On Wed, Jun 26, 2024 at 10:07 PM Peter Relson wrote: > Gil wrote > > Eerily reminiscent of a Red Alert IBM issued a couple years ago. A macro, > customer facing therefore hard to change, was doing a STCK to a wild > address. When a certain bit in the TOD changed, IPL cod which tests that > bit with no effect other than to crash when it had the wrong value would > make the next IPL impossible. > > > That seems unlikely, and almost inconceivable unless you IPL without > "clear" (aside from if the corrupted storage got written to a data set that > was read upon re-IPL). > > Might you have any details? > > I certainly understand relatively unpredictable side effects within the > current IPL, > > Peter Relson > z/OS Core Technology Design > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Epoch Index
Attila F wrote STP provides that non-z/OS persistent data store that can cross IPLs. Nothing was coming to mind that matches a statement like that. It is true that certain STP attributes can be set by the OS and remain in effect upon the next IPL of the partition, but that's not a "data store". Can you clarify? Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
