On 08/15/2010 03:07 PM, Paul Gilmartin wrote: > On Sun, 15 Aug 2010 08:23:18 -0400, Shmuel Metz (Seymour J.) wrote: > >> In <listserv%201008131709378676.0...@bama.ua.edu>, on 08/13/2010 >> at 05:09 PM, Paul Gilmartin said: >> >>> I'll agree enthusiastically except where the change could be made in >>> a compatible manner, altering no sizes, displacements, nor content of >>> existing data bases. One example might be that where Dec. 31, 1999 >>> is represented as x'99365', Jan. 1, 2000 could (have) been >>> represented as x'A0001' >> >> That would not have been compatible. >> > Well, yes. The entire 21st century is intrinsically incompatible > with software incapable of formatting dates past 1999. I merely > suggested that bit patterns previously deemed invalid could be > used (as a stopgap, I failed to say) to encode a further range of > dates until necessary changes in data formats can be made. > > -- gil
The point of Shmuel's comment, of course, is that the one most common, unavoidable-in-MVS place where dates of the form yyddd were in wide-scale use was in SMF accounting records. The format there is packed-decimal, so hex digits are out. The old format was actually +00yyddd, where the 00 was reserved, so the one and only way to preserve the packed decimal representation and also preserve the existing relationship that the representation for the next year is current year + 1 (in base 10) was to go with 2000-01-01 == 0100001, which is what IBM did. For those who were already converting SMF dates into a four-digit year via 00yyddd + 1900000, this extension was so compatible that it wasn't even necessary to make any code changes for Y2K! Granted, if you had existing databases or files with 3-byte-decimal or 5-character YYDDD dates, you had a much more serious problem. Any way you went, using-unused bits, expanding the field, at some instant the field definition would change and all code touching that field had to be revised accordingly. Except for separate interpretation rules for older archived data, it always made sense to us that if you had to change a field and all related programs it was best to stick with simpler representations that avoided future headaches. If a larger field was unacceptable, a 3-byte integer Lilian date is much simpler to work with in the long run than having different bit-twiddling rules for different digits of the year. The original question raised of what date formats should be supported by a conversion routine has a different answer if the object is to support a single installation rather than for a general purpose vendor utility. It makes sense that local installation standards should try to minimize the number of different date representations used locally to minimize confusion and needless conversions. -- Joel C. Ewing, Fort Smith, AR jcew...@acm.org ---------------------------------------------------------------------- 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
