Please explain to me where future TOD/ETOD values are needed in
application code. Especially business applications. I'm fairly sure that
it's a rare application that stores future date/time values in TOD
format.
Please understand, I'm not talking about log timestamps, even
transaction logs. But, I have a hard time envisioning the need to
evaluate or compare or most especially store a TOD format much more than
24 hours ahead of now.
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On
Behalf Of Joel C Ewing
Sent: Saturday, April 11, 2009 12:50 PM
To: [email protected]
Subject: Re: "New" TOD
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
----------------------------------------------------------------------
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
