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
