As we approach the end of the 20th century we may look forward with anticipation to the challenges we will face as we begin the new millennium. We may also look forward to the giant celebration which will take place on December 31, 1999. However, if we are users or managers of computer systems, we must be aware that a potential catastrophe lurks which, if not addressed, may give us a hangover that will last far beyond January 1, 2000.
On that day, some experts predict, computer systems around the world will grind to a halt. Why? Simply put, the technological meltdown looms because of a lack of forethought--and the absence of a couple of digits.
In the early '60s and '70s, computer resources were scarce and costly. Memory, disk space and processing power were all very expensive compared to their cost today. Developers of early computer systems had to be very careful about how they used limited computer resources. Furthermore, it was assumed (and we all know what happens when you assume) that computer systems developed in the 1970s would be retired and replaced long before the year 2000.
One effective way to conserve memory, disk space and even data entry was to store and process dates as a series of two-digit numbers. For example, May 15, 1976 is stored as 76 05 16, not 1976 05 15. Thus, there is no accommodation for the new century in the two-digit format. The result is that many computer systems will fail or, perhaps worse, provide invalid results as they attempt to use the year "00," not recognizing that the year is actually 2000, not 1900.
On the first day of the year 2000 all calculating and sorting programs using two-digit years will become obsolete and unreliable. Procedures involving sorting by chronological order won't work, because the year 2000, stored as 00, will be shown as occurring before earlier years.
For example, if you were born in 1966 and a computer system has your year of birth as 66, then your age today is 96-66=30. When we reach the year 2000, your age will be calculated as 00-66=-66. Of course, it should be calculated as 2000-1966=34. This type of error may occur everywhere: student records, pension projections, life insurance calculations, inventory control systems, interest charges on credit card payments, etc.
This practice of storing the date without the century has also been used in many recently developed systems so that the problem, although more prevalent in our older legacy systems, is by no means restricted to systems running on mainframes. Any PC system doing date processing, if incorrectly designed and programmed, has the same potential for errors as the large legacy systems.
There is also a misconception that these errors will only begin to appear in the year 2000. In fact, some errors have already begun to appear, and systems have had to be corrected to resolve the problems. For example, a bank sold a Certificate of Deposit with a 6-year term in early 1995. Everything worked fine until they tried to pay the first month's interest. It brought down an entire system trying to figure interest (backwards) to the year 01. McGill's Student Records System will need to be adjusted no later than the summer of 1998, when records will be created for data pertaining to terms in the year 2000.
So what's the big deal? The Gartner Group, a computer information service, puts the world-wide expenditure needed to rectify the so-called "millennium bug" at $300-$600 billion U.S. A major issue has been convincing upper management that their computer systems, and hence their operations and businesses, are at risk, and that significant resources will have to be allocated to fix the problem. Companies have limited resources to accomplish whatever modifications they need to make to their systems, and the Gartner Group estimates that fewer than half of the companies affected by the problem will complete their task in time.
The simple alternative to addressing the problem will be going out of business, said the Gartner Group's Kevin Schick in testimony on April 16 before a U.S. congressional committee looking at the impact of the millennium bug on U.S. government agencies.
What are we doing about this problem at McGill? A project team from Information Systems Resources (ISR) has been created to address this issue. We are currently in the impact analysis phase of the project, that is, attempting to determine the impact of this millennium bug on our central computer systems. To this end, we are in the process of taking an inventory of our 8,000-plus programs and 2.5 million-plus lines of code to determine which files and programs need to be modified.
Together with our clients, we will determine what has to be changed, how to change it, and establish priorities as to which systems to modify first. The second phase will involve making the changes and testing them extensively, while the third phase will involve implementing "Y2K- compliant" systems.
In some cases it may mean changing the data to include a century as part of the date field, and then making, testing and implementing the appropriate changes to take the new date format into account.
Or we may choose to leave the dates as they are on the file without a century, but write a bridge program that will enable other programs to act as if the dates were in the proper format. In other instances, money, time and resources permitting, we may decide to scrap the old system before problems begin to appear, and take the opportunity to purchase or develop a new, improved system.
All is not as bleak as it seems. Although we don't wish to minimize the effort that may be required, we believe that as far as central administrative systems are concerned, we may be better off than other information systems sites because: all systems developed in the last 6-8 years are Y2K-compliant; the new Interactive Staff Information System (ISIS) which is nearing completion has been written to correctly process dates in the year 2000 and beyond; and Student Records is the only major system affected.
We hope to complete all work by early 1999, so as to have that year for any last minute emergencies or for resolving bugs that arise.
Any PC systems which run locally in your departments may contain problems similar to the ones we will encounter in our central systems, if those systems do date processing and have not been developed with the year 2000 in mind. For example, departmental accounting systems, departmental payroll systems and building security systems may either cease to work or produce incorrect results.
Regardless of whether the programs are written in COBOL, FoxPro, Visual Basic or C++, if your files, databases and spreadsheets have not been designed with the century in mind, and if you do date selection, processing, calculations, sorting, etc., chances are you may encounter problems even before the year 2000. Doing the actual work on PC systems will be the responsibility of individual system maintainers.
One important legal note is that any department considering the purchase of a new system, be it student records, fundraising, purchasing, financial, etc., should ensure that the contract specifies clearly that the software being acquired is Y2K-compliant. Otherwise, if things start going haywire at the turn of the century, it will be your responsibility--and not the vendor's--to rectify the problems.
In the near future we hope to create an ISR Web page dealing with the Y2K problem, where we will attempt to keep the McGill community abreast of problems and solutions encountered on campus. For those interested in getting more information on the topic, you can look on the Internet at www.year2000.com. There's enough material there to keep you busy reading until almost the year 2000.
You can begin to think about addressing the possible problems now, or wait until 1999 when you will have more time on your hands. We would suggest, however, as ISR is doing, that you begin to take corrective action as soon as possible. That way, December 31, 1999 will indeed be a night of celebration!
Allan Levine
Year 2000 Project Manager