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
