There are what looks like some very versatile z/OS macros to convert
"readable" date-time values to and from TOD and ETOD values, which
someone might be tempted to use as a basis for date-time manipulation.
It is still a documented restriction (don't know if it is actually true)
that even when ETOD values are used that dates handled by these macros
must still fall within the 2042 limitation. This is an example of
things that obviously need to change well in advance of when the actual
ETOD overflow occurs into the high order byte, so that code can be
written and tested using dates beyond 2042 well before 2042 arrives. A
database with projected retirement year for new hires would already be
using dates past 2042, and in 3 years 30-year mortgages will go past
2042; so it is presumptuous to assume we have plenty of time before full
post-2042 support is required by z/OS.
At some point in the near future the formal definition of STCKE should
be changed to merge in the high-order byte as part of the binary
integer, and z/OS interfaces changed to support nonzero values there.
It wouldn't be unreasonable to continue for another 20 years with the
restriction that actual hardware couldn't support nonzero values for the
high-order byte for current date-time hardware ETOD clock, but one of
the lessons of Y2K is that application software can persist for 30 years
and delay on the software interfaces will only cost us later.
J C Ewing
john gilmore wrote:
I confess that I have found this thread puzzling.
IBM has provided the "fixes" needed to cope with the overflow of the traditional 8-byte/64-bit STCK value that will occur in September 2042. They take the form of an STCKE value which is 16 bytes/64 bits in aggregate size Its structure is not, however, so simple as that of an STCK value, which is a single 64-bit unsigned binary integer.
The STCKE has three components. From left to right, low to high storage address, they are
+-----+
| x'00' |, a one-byte prefix,
+-----+
+----------------------------//---------+
|<---104-bit unsigned binary integer---->|
+---------------------------//----------+
+-----+-----+
| | |, two-byte TOD programmable register.
+-----+-----+
I leave it as an exercise for the reader---The answer can be found in at least one Redbook---to determine when this register will overflow for the epoch origin midnight, 31 December 1899; but
2^104 = 20,282,409,603,651,670,423,947,251,286,016.
Timely support for STCKE values will certainly be provided (is in some cases already provided) in statement-level procedural languages and the like.
HLASM programmers do, however, need to replace STCKs with STCKEs and make the necessary target field-width changes in existing code (and, of course avoid STCKs in new code); but this has been obvious for years.
John Gilmore Ashland, MA 01721-1817 USA
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
