If you are a programmer or a manager who isn't prepared, the holiday break in 1999 will be notable and lengthy. The impact can be enormous: time may go back to 1900 or 1980; your security gate may open on Saturday, thinking it is Monday; the program you wrote may incorrectly calculate the year as not a leap year; or the tape your created and vaulted may be erased prematurely.
Many data professionals have been planning and working on the potential, impending technological disaster for years. Some are leveraging the required maintenance and protecting their investments in applications and data into the future.
Here is a sample of computer problems that will keep programmers working for the next four years:
Let us start with the simple 2-digit year date used to save keystrokes and storage space.
€Try entering 00 into a 2-digit year field on a full screen application. If the application is several years old, the programmar in the 1980's probably coded a filter for the correct year. He/she checked for the year ending between 80 and 99. Little thought was given to the 2-digit century value or how to program through this challenge. Who would have thought they would still be programmers in the Year 2000?
€It is Friday, December 31, 1999. The PC based access security system works on a date configuration using a 2-digit year. It is 12/31/99. At midnight it will be 01/01/00. January 1, 2000 is a Saturday. January 1, 1900 was a Monday. Was the programmer smart enough to code for the Year 2000 and beyond or is your system disabled, thinking the year is 1900?
€Some programmers code the date as a YYMMDD formatted field. Your Aunt Peg cans peaches that stay preserved for about two years, and gives you a batch every year. Using the YYMMDD format, New Years Eve will be 951231. New Year's Day will be 960101. If you subtract 951231 from 960101, you would receive a positive non-zero number less than 20000. Your Aunt Peg's peaches are still tasty and firm. Using the same scheme for the Year 2000, if you subtract 991231 from 000101, the result is negative. Uh-oh, their 'best used by' date expired overnight. Can you imagine how many cans of peaches your Aunt Peg would be throwing out, if her little operation grew, became a highly computerized company and relied on a YYMMDD date test for freshness?
No problem you say, I'll restructure the year to a full 4-digit year or the date to a YYYYMMDD format field. 'If I could only find the $%^#&;source code.' Once you retype the source code from an old listing, the bigger problem arises: the no longer supported OS/VS COBOL compiler still returns the 'CURRENT-DATE' as a MM/DD/YY field. You must buy a new compiler to support the 4-digit year.
€If you create a tape payroll master on December 31, 1995 and wanted to keep it for seven years, you could code the dates in Julian format. (A Julian date format contains the year in digits 1 and 2 and the day in digits 3 through 5 as 1 through 366.) The file would be created on 95365. It's expiration date would be 02365. The tape expires overnight and never reaches the vault.
Some systems are still coming out today with the BIOS problem! The good news is that more PCs are being produced today that will automatically update the century correctly. Remember a manufacturer's product life is under two years. Your boss sees the PC's life cycle as over five years. Routines are being coded for many of these current models that will execute in AUTOEXEC.BAT to correctly change and handle the century.
This is only the start. The list of other potential problems goes well beyond coping with the 19xx / 20xx problem. Some other areas include the 16 bit integer date of century routines; users who use dates as data keys; hard coded expiration dates such as 99365, mainframe date service calls, etc.
All of us will be affected. We can deal with the problem now or we can deal with the problem later. It won't go away.
For a long time, the programming community has been aware of the complications with the Year 2000. William Goodwin in Brooklyn, N.Y. publishes a newsletter entitled 'Tick, Tick, Tick'. Kevin Schick from the Gartner Group speaks on the topic. Peter de Jager, another industry speaker on the topic has a Web page
Even IBM's Large Scale Systems announced its embracement of the Year 2000 dilemma
<ftp://lscftp.kgn.ibm.com/pub/year2000/y2kpaper.ps>
New applications are being written with fully expressed dates. The C&IS;programming groups have been reprogramming date dependent code. These enhancements can be implemented when ready and don't need to be kept on the shelf waiting for the Year 2000.
If you feel you might be exposed the universal advice is: Identify your files. Inspect your data. Analyze your programs. Get a detail perspective of the affected areas. Scope out the effort to fix the problem. Re-examine your options i.e. change the data vs. change the program. Watch your time. Test and implement your changes. Watch your time.
Think the Year 2000 won't affect you? Take out your checkbook and look at the check date field (____ 19__).
George Klocek is a Senior Research Programmer for Computing and Information Systems.
Back to December 1995