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 00000000_00000000 will be "later" than (the negative) FFFFFFFF_FFFFFFFF. 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 [email protected] with the message: INFO IBM-MAIN
