The Millennium Bug—Do We Have the Right Antibiotics?

AORN Journal, March, 1999 by Kurt W. Remmert

The moment that the year changes from 1999 to 2000 the world may be infected with a disastrous infestation of one of the most unintentional but predictable and preventable burs known to modem humans. The bug we face is called a number of things, but the most common names for this infestation are the "Millennium Bug" and the "Year 2000 (Y2K) Bug." This article brings to light some concerns that are being voiced regarding the progress made to date by the health care industry as well as industries that affect our daily lives. The millennium bug is not a problem that concerns only the United States or health care. Not only do we need to be concerned with how software and hardware will function on Jan 1, 2000, but we also should be asking suppliers, utility companies, and financial institutions about the status of their Y2K projects.

All of the information gathered for this article is readily available on the Interact. Many organizations are sharing the how and why of what they are doing and the progress that is being made. The information spans the spectrum, from "We're doing a great job and will be ready on time" to "Run for the hills."

THE PROBLEM

The Y2K bug comes in a number of varieties. These varieties can be categorized loosely into two basic areas--software and hardware. Both areas have separate origins, solutions, and associated problems. When we look at resolving these diverse issues, we must keep in mind the overall result we seek--to have the electronic infrastructure functioning on Jan 1, 2000.

SOFTWARE

The software portion of the Y2K bug has its origin in the 1960s, when computer systems used paper punch cards and expensive magnetic storage media for data input, output, and storage.

Hollerith punch cards. One of the commonly used methods for data input was the Hollerith punch card. Each rectangular card held a limited amount of information. With this thought in mind, as much information as possible was squeezed onto each card. One idea, intended to save space, was to store the date in a year-year month-month day-day (YYMMDD) format (eg, 530108 for Jan 8, 1953). The century number (ie, 19) was added by the software as it manipulated the date.

Magnetic storage media.

Another reason for formatting' the date as YYMMDD was the cost of magnetic storage media during this time period. The cost of one megabyte of magnetic disk storage--the amount of information in an average-size novel--was approximately $761.(1) The equivalent cost today would be approximately $0.75. To best use this space, computer programs were coded to require the storage of only two digits to represent the year. Even though the date-storing process was due to space and economic reasons, after a short time, it became the conventional way of handling dates.

Longevity. Very few programmers in the 1960s and 1970s believed that the software they wrote still would be in use at the turn of the century. One programmer familiar with the practice said in an interview, "We didn't think the systems would still be running. Computers were evolving so rapidly back then.(2)

THE SOFTWARE PROBLEM

The real problem comes not from how computers store the date, but how they see the date. Remember that computers are literal machines--they only act on instructions and information given by humans. Basically, what we have told these machines is that the first two digits for the year must be "19."

When Jan 1, 2000, comes along, the old programs will see only "000101" and will interpret the year to be 1900. As this date may be used in a number of ways within the computer program, problems may arise with any calculation using this erroneous date. For example, we want to calculate the dose of a particular medication based on the patient's weight and age. We will not have a problem calculating the weight part, but when we factor in the age, things get confusing. The hypothetical patient was born in 1995. The current year is 2000, which makes this patient five years old. When the computer tries to figure the patient's age, it subtracts the year of birth (ie, 1995) from the current year as the computer interprets it (ie, 1900) and determines that the patient is -95 or 95, depending on the logic written into the program. You can see where this may cause some errors. Anytime there is a date calculation the information may not be correct or, depending on the logic written into the program, the system may see the erroneous date and stop working.

Fixing the problem. What must be done to fix the software problem is to change how the computer interprets and stores the date. Instead of using just YYMMDD, computers will have to use YYYYMMDD (ie, 20000101 for Jan 1, 2000) and process all four digits of the year.

This may seem like an easy, straightforward solution to the problem; however, we must keep in mind the size of the programs that are being used. Large business systems may have anywhere from one million to 100 million lines of programming code. Each line of code must be examined to see if there is a date calculation performed. Assume that a computer programmer can look at one line of code in one second to determine if that line calculates a date and, for the sake of this example, the computer system has 50 million lines of code. Assuming an eight-hour work day and a five-day work week, the programmer would need 6.7 years to look at all the lines of code. If you had 10 programmers checking this one program, it would take only eight months. That may not sound too bad, but after they find those date calculations they have to fix them, test them, and then fix any remaining problems. To make matters worse, we now have to look at every instance where we already store dates and either change the dates or tailor the solutions to interpret the dates correctly. In a speech presented at the National Academy of Sciences on July 14, 1998, President Clinton said, "With millions of hours needed to rewrite billions of lines of code and hundreds of thousands of interdependent organizations, this is clearly one of the most complex management challenges in history."(3) You can imagine how big this problem really is.