> -----Original Message----- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of john gilmore > Sent: Sunday, April 12, 2009 11:33 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: "New" TOD >
<informative stuff nipped> > > It is also worth noting that that, while Julian or Gregorian day numbers > preserve enough detail for most applications, they do not always do so, > even for business applications. SWIFT-transaction processing, real-time > demand/current deposit accounting (DDA/CDA), real-time medical-record > maintenance and the like all make use of and require the use of full date- > and-time values; and for them ETOD values are convenient where they ar not > too municipal. This thread (or my question at least) started by my questioning the statement that since we are coming up on 30 years before the TOD rollover, IBM is already late in solving the specific TOD problem. I maintained that it is unlikely that any current processing uses (E)TOD formats with values > "whenever" 2042. Your examples, while real, still involve values that are today, not to long ago (relatively) and surely not much past tomorrow in actual calculations and/or stored data. You are also correct that any effective use of date/time calculations is facilitated by the epoch approach. Storing date/time in any format where the beginning and ending of the available range are not known, explicitly (your examples, or (E)TOD for that matter, or by convention yymmdd (windowed) yyyymmdd is faulty data processing. Y2K was an issue. We knew it was coming and for the most part handled it. 2100 as a non-leap year and (E)TOD are both known. And with 100 year leases, presumably, handled where needed or if not, are in error needing repair. Contrawise, anyone who actually spent money on disk or memory or space on the cards back when the constraints were real may well not have remained cost effective. I can remember when making a commonly used field one byte longer translated into at least 5 or 6 figures in DASD cost. And we've always been a small shop. Expensively solving a problem before it's time is a questionable use of limited resources. > > John Gilmore Ashland, MA 01721-1817 USA > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
