In 1979, I Ieft IBM for a speculative venture developing software on the "new" Z80 and 8080 machines.
One of the first applications we developed was a whisky stock control system that could calculate accruals on whisky casks stored in bonded warehouses. The company in question received invoices for casks when they were fully drawn from bond. For many years they had just paid up, because it was too hard to verify. The first question was "how many days was it in bond". The solution we used was to always store a date as a relative day number (relative to 1 Jan 1900). Once the date was stored that way, the calculations were fairly simple. We had a to/from subroutine that would calculate the day number or date. On 1 Jan 2000, I was in the board room of a major mutual insurance company in Melbourne. About 6 of us watched the fireworks and of course, nothing happened. We had done a lot of work to prepare, so it paid off. In the following days a few things broke but they weren't mission critical. On Fri, Jan 3, 2020 at 11:52 AM Joel C. Ewing <jcew...@acm.org> wrote: > Around 1990 it became clear that our installation needed some > alternative to a universally-used, in-house date subroutine -- one which > supported all sorts of date calculations, conversion between several > different formats, offsets from dates, day of week adjustments, etc. It > had been extended and modified many times, and depending on the type of > request the same field in a complex structured parameter block might be > used as input, output, or just ignored. In other words, it was next > to impossible to be sure there weren't some unintended behaviors that > someone had learned to exploit, and it was equally certain there was no > way to verify the unstructured code was even 100% accurate for pre-2000 > dates. Since it used two-digit years and base-1900 windowing, the old > date routine would clearly fail for dates or date calculations crossing > the year 2000 boundary. > > Before 1990, I had encountered the B.G. Ohms article "Computer > Processing of Dates Outside the Twentieth Century" in the IBM Systems > Journal, (Vol 25, No 2, 1986, pp 244), which suggested use of what the > author called "Lilian date format" (days from Oct 15, 1582) to simplify > date computations. I used that as the base internal date format for a > new structured date routine, which handled all sorts of date format > conversions, date calculations, relative and absolute date windowing to > convert two-digit to four-digit years, etc. and we started phasing out > use of the old date routine to eliminate the most obvious common point > of failure. > > From 1997-1999 various tools and significant person-hours were used to > locate two-digit year date usage in over 10,000 in-house application > programs, which were then remediated with four-digit years and tested on > a test system running with future dates. There were some cases, mostly > involving data entry, where it made sense to allow > relative-to-current-year windowing to convert two-digit years to four > digits, but absolute windowing was strongly discouraged and dates > retained in external files were converted to four-digit years. > > As others have noted, solving the immediate Y2K problem by merely > changing two-digit years to use a different absolute-base windowing > scheme was a questionable temporary solution, creating yet another, > potentially more-costly problem in the future. > > Our Y2K remediation efforts found and fixed many potential problems that > would otherwise have made the first several months of 2000 chaotic. As > a result, the transition from 1999 to 2000 was uneventful with no > significant problems. > > There were no "hacks" of which I was aware from IBM to ease the > transition, unless you count changing the definition of year values in > SMF records from "00YY" to "01YY" for dates past 1999. There were of > course various PTFs to fix any issues with four-digit years in MVS and > in IBM applications. I recall one notable PTF to fix an erroneous > leap-year determination in ISPF that even turned up pre-Y2K in the early > 1990's -- a good example of why date calculation code should avoid > clever efficiency over obvious and verifiable algorithms. There were > some offerings from 3rd party vendors. There were also a steady stream > of "crackpot" easy-fix suggestions on newsgroups in the late 1990's from > people not understanding the issues, and in 1999 from alarmists > predicting failures of computer-based control devices that that had no > logical reason to be using dates in any significant way. > > The problem for us was not "how" to fix a single instance of the > problem, but finding "where" to fix an unknown number of instances of > the problem in 1000's of lines of in-house code and in associated data > sets. > JC Ewing > > On 1/2/20 3:06 PM, Pommier, Rex wrote: > > Hi Ron, > > > > I think the rolling century was implemented at a lot of places. IIRC, > didn't DFSort have something like that as well as SAS? The company I was > at over Y2K went through and converted everything to 4 digit years. I > believe the one I'm with now did the same thing. > > > > Rex > > > > -----Original Message----- > > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On > Behalf Of McCabe, Ron > > Sent: Thursday, January 2, 2020 2:50 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: [External] Re: it was 20 years ago today > > > > Question about how the year 2000 was handled as we just got hit by a > major date problem. I remember that one way to handle the date comparisons > was to have all the years from 00-19 (or something greater than 19) have a > high value so it would be greater than the 1990's. Does anyone remember > that? Was it something IBM did although I don't recall putting on any > patches for something like that so I'm thinking it was something we did. > > > > Thanks, > > Ron McCabe > > Manager of Mainframe/Midrange Systems > > Mutual of Enumclaw > > > ... > > -- > Joel C. Ewing > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Wayne V. Bickerdike ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
