MILLENNIUM ROLLOVER: THE YEAR 2000 PROBLEM At one second after January 1, 2000, millions of people will celebrate the beginning of a new year. Many people will also rue the day because of computer hardware and software problems that will create havoc for those who are not prepared. Simply put, many hardware and software systems will cease to work or will produce wrong answers when the year 2000 arrives. This bulletin provides information that CSL has collected from a variety of sources on the extent of the year 2000 problem, what organizations are doing about the problem, and where help can be found to deal with the problem. The Year 2000 Problem For 30 or 40 years, programmers have stored date information in "mm/dd/yy" format to conserve space in disk storage and computer memory. They adjusted computations to take the two-digit year into consideration when computing time periods, ending dates, and the like. Programmers represented years in the twentieth century as two digits without considering what might happen once the year 2000 rolled around. At that time, most programmers and project leaders figured that their programs would not last into the twenty-first century. In hindsight, it seems these people should have known better, but they were trying to perform a service to their management by conserving expensive disk and computer memory. Adding two century digits to a date field for a 100- million record file would have added at least 100 megabytes of storage requirement to a disk that cost upwards of $20,000 for 15-20 megabytes. It made economic sense to lop off the two century digits. Now, the industry faces the problem of adding those two century digits back into the date field in order to keep software running and producing correct output. The problem, however, is not isolated to software. Hardware will also cause difficulties for system administrators and chief information officers. System clocks on virtually every personal computer will wind up with corrupted dates on January 1, 2000. In some cases, the date will appear to roll over to the correct date, but when the machine is turned off and then back on for the next session, an odd date will have taken its place. It may appear as January 1, 1980; January 4, 1980; January 1, %000; or some other combination of characters, all of which will produce erroneous results. The dilemma is not limited to personal computers. Some workstations, minicomputers, mainframes, elevators, and automobile central computers will fall victim to the insidious problem. In most cases, software patches can alleviate the problem to a more-or-less livable extent, but in some cases, the date issue can be resolved only by replacing the hardware. In software, the problem will be most visible in sorting routines that sort on two-digit year fields. Storing 1999 as 99 and 2000 as 00 will cause the 00 date fields to sort out before the 99 date fields. The consequences of this action can be determined only after the context of its use is understood. Additional difficulties will crop up, and already have. In one case, a bank's irreplaceable backup tapes were almost used as scratch tapes when a mainframe operator discovered the discrepancy and pulled them from the scratch tape bin. The problem came from the tape management software's use of the date "00/00/00" as the scratch tape indicator in the tape label retention date field. In 1995, tape backups were made with a retention date of December 31, 2000, which was stored in the tape header as "12/31/00." The tape management software looked at only the year portion of the retention date and decided that they had been around long enough. Thank goodness for the observant operator! Year 2000 horror stories abound, all with the same lesson to be learned. Hopefully, senior executives and chief information officers will realize the severity of the problem and take preventive action. Unfortunately, the solution is expensive and labor-intensive, but there is hope and experience from those who have already taken corrective measures. What Organizations Can Do About the Problem William M. Ulrich, in Application Development Trends' February 1996 issue, describes the essential elements of a strategy for assisting organizations in solving the year 2000 problem. These elements include:  performing an enterprise-wide assessment of the extent of the problem;  assessing the infrastructure in place and additional requirements to support any new functions associated with the solution;  deploying strategies for solutions;  defining validation strategies for testing modifications and assessing the compliance of new software to standards; and  detailing budgeting strategies. Foremost in deciding what to do is estimating the extent of the problem. For software, the Gartner Group estimates that it will cost between $0.50 and $1 or more per line of executable code to analyze, modify, and test the software. Organizations in general have found that 1-2 percent of code will be affected and will have to be modified, but all of the code must be analyzed to make this determination. Estimates translate into one staff-year per 100,000 lines of code! Some organizations, such as banks, may have as many as 10 million lines of code with a higher affected rate than organizations that use information technology to keep accounts, mailing lists, personnel records, etc. This translates into 100 staff-years of effort. Time is of the Essence Once the extent of the problem has been defined, organizations need to formulate a time frame for corrective action and start the process as soon as possible. All of the work should be done before the start of the year 1999 in order to have a sufficient shakedown period for testing changes. With only 220 effective workdays per year (after two weeks of vacation, holidays, and sick leave are factored out), approximately 600 workdays remain until the end of the year 1998. One hundred staff-years over 600 days requires at least 35 persons working on the problem full- time. A large organization may spend between $5 million and $10 million on corrective action. The Gartner Group estimates that Fortune 500 companies will spend between $10 million and $40 million each. Worldwide, the figure is $300-600 billion. Table 1 presents statistics collected over the last six months from various messages and notices on the World Wide Web (WWW). While not rigorously measured, these figures give an indication of what others have found in trying to deal with the enormity of the problem. The average from this information is that 167,000 lines of code per staff-year can be analyzed, modified, and tested. The scope of the problem for individual organizations can be bounded using a ballpark estimating factor between 100,000 and 167,000 lines of code per staff-year. Table 1. Size and Effort Estimates Comments Lines of Code Estimated Staff-hours Manufacturing system 1,200,000 2,000 Commercial off-the-shelf (source code was available) 2,000,000 2,500 2,000 programs 7,000,000 38,000 Retail system 7,500,000 75,000 401K system 1,300,000 9,000 7,000 COBOL programs (83% were affected) 12,000,000 200,000 ---------- ------- TOTAL 31,000,000 326,500 ========== ======= A Plan of Action The most reasonable solution is to attack the problem one step at a time. A suggested means of planning for the work may include the following steps:  Select a product to assist in managing the inventory of software and databases involved. Select one or more products to assist in analyzing the software and estimating the extent of the problem. Some of these products will also modify the software and data automatically, but cannot do so for every case. (Some computations are date-related, but cannot be determined from the source code. In such cases, an individual must analyze the source code line by line.)  Inventory applications, libraries, databases, extraneous files, documentation, and other items that have importance within specific systems. Identify who is responsible for each item.  Analyze the applications and data. Estimate modifying the source code alone to change those locations that perform date computations and logic operations based on dates. Perform a second estimation that includes modifying databases and all source code that references data fields and all source code affected in the first estimate. If there is an insignificant difference between the two estimates, the recommended course of action is to modify both the databases and the source code. It may be less expensive in the short run to modify only the source code, but more expensive in the long run if maintenance problems crop up over time due to the date processing fixes.  Assemble a team of programmers, application experts, database designers, and project management based on the overall system requirements. Once estimates are known, the number of personnel required can be determined, particularly in view of the automated tools selected for use.  Modify the system. Three major options are: a) modify the source code to manipulate and perform computations on dates with century digits included; b) use a sliding window time frame to determine date context for computations; and c) incorporate packed date fields and use specialized subroutines for performing the computations. All three of these are expensive and may lead to further maintenance problems in the long run.  Test the modifications. Allow 40-50 percent of the overall project resources for testing, even more if the database is modified. This includes testing documentation to ensure that directions are correct and correspond to the changes made. Sources of Help for Dealing with the Problem The major obstacles in succeeding with a year 2000 problem are:  getting executive management to acknowledge the problem and take serious action;  finding the right suite of tools to assist in the conversion process; and  enlisting the help of knowledgeable professionals. Executive management must be made aware of the problem and its severity before anything can be done about it. The problem is a show-stopper. The solution will consume lots of resources. How does one go about telling management that the organization must invest large amounts of time and money into a project that will allow the organization to continue business as usual? There will be no added value or improved productivity; management will gain only the knowledge that on January 1, 2000, the organization may not have to go out of business. Professionals in the field can describe in much finer detail the consequences of ignoring the problem. Past naysayers have become proselytes once confronted with their own ignorance of the problem. Peter de Jager, a Toronto-based consultant and motivational speaker, has numerous anecdotes and statistics that he uses to help organizational management "see the light." He has been speaking on the year 2000 problem for ten years and publishes some of his work on the WWW at URL "http://www.year2000.com/" where he has established the Year 2000 Information Center. Under his "http://www.year2000.com/links.html" index are links to other articles and publications on the year 2000 phenomenon. Vendors, consultants, products, and services* are available through de Jager's home page. Brochures on specific products and their capabilities are available through WWW links at the Year 2000 Information Center. A great deal of technical expertise and discussion can be found on the Year 2000 discussion group administered by de Jager. Membership can be obtained simply by sending electronic mail to listmanager@hookup.net with the message "SUBSCRIBE YEAR2000" (without the enclosing quotation marks) in the body of the message (not in the subject line). For federal organizations, the Federal Information Resources Management Policy Council (FIRMPOC) has a work group in place to identify issues and recommend actions concerning the year 2000 problem. Kathy Adams (410-965-6294, kathy.adams@ssa.gov) of the Social Security Administration in Baltimore, Maryland, chairs the group. The group provides agencies with a definition of year 2000 compliance and issues a recommendation on contract wording to that effect. The Office of Management and Budget (Ed Springer, 202-395-3562, springer_e@a1.eop.gov) has also taken an active interest in the year 2000 problem. Conclusion Organizations that recognize the impact of the year 2000 problem and take action to remedy it will have a distinct advantage over those that do little or nothing. It is a severe, immense problem, and all anyone can do is plan for its solution. It will not go away and it will most assuredly make itself known on January 1, 2000. *Mention of any product, service, company, or individual at this source does not constitute a recommendation or endorsement, explicit or implicit, intentional or implied, by the National Institute of Standards and Technology.