ASSOCIATES (vol. 4, no. 3, March 1998) - associates.ucr.edu
*YEAR 2000 DATE CONVERSION: AVERTING THE DANGER* by Mary Iber Specialist II at ACT Library with specialty in Serials Iowa City, Iowa mary-iber@uiowa.edu THE PROBLEM The Year 2000 Date Conversion project may be the most extensive and the most expensive challenge computer technology has yet encountered. The Millennium Bug, or Y2K, has the potential to crash networks, bring industries to a standstill, and cripple computer applications around the world. It seems incredible that two zeros could be the cause of such wide ranging problems, but it is true. The Gartner Group, a technology research firm, estimates the cost of fixing this problem at $300-$600 billion worldwide. (Kappelman, Cappel,1996) Unlike most Information Systems projects, this one has a fixed deadline: December 31, 1999. Why are these two digits (00) so significant? Since programming began, most date fields have been entered as six digits, with two digits representing the year. Most calculations can and have been working well with this representation, until we come to the turn of the century. When the date "00" is entered, the computer will usually interpret that as 1900, since the default for the first two digits of the year field has been "19." To complicate matters, the year 2000 is a leap year, but 1900 is not. IMPLICATIONS In practical terms, what does this mean? If the problem is not fixed, any data involving years from different centuries will cause an incorrect output. Someone born in the year 2000 will be interpreted as being 100 years old. Items sorted by date will be out of order. Data files which are programmed to be saved for 5 years will be deleted, since the computer reads them as being 95 years old. Expired passwords, corrupt data, and failed applications will influence computers belonging to business, industry, government, schools, and individuals unless remedial action is taken soon. Computer chips operating elevators, ATM machines, security systems, copy machines, and even military missiles could have programming that would prevent proper functioning if not compliant. CAUSE In the late 60's and 70's, computer memory was so expensive, and speed was so slow, that any characters eliminated was a huge savings. Abbreviating the year to two digits was a cost- and a time-saving measure. Most programmers did not think their programs would still be running in 30 years, so did not anticipate the Y2K problem. One way of storing data was on a punch or Hollerith Card. These cards could only hold 80 characters, so the choice to eliminate 4 characters per date (using 210751 rather than 21/07/51) was very cost effective. (de Jager, 1997) This choice made in the 1960's has led in the 1990's to the most pervasive and expensive problem that technology has ever faced. SCOPE Any system that processes dates is involved, which includes about 90% of all applications. Hardware and software are affected. Legacy systems and major applications still use code written in the early computing days. No industry standard existed for entering dates, nor was there a common programming language. Many of the languages used no longer have programmers who know them! Although this problem was thought to be mainly located in older mainframe systems, it has been found in every level of the computing industry. One author testing his IBM computer purchased in 1995 was surprised to find that even it was not compliant. (Efken, 1997) The legacy mainframe systems usually follow a typical pattern and are written in COBOL programming language. The number of lines of code to be fixed is monumental, but there is a consistency to the job. With the newer client/server architecture, the variety of both vendors, and language codes is so diverse that the problem becomes significantly more complicated to determine and fix. In order to be fully Year 2000 compliant, all aspects of all hardware and software must be in compliance, and be able to work together. (Ulrich, Hays, 1997) PROGRESS REPORTS - GOVERNMENT The Gartner Group estimates that the federal government will need to spend $30 billion to fix the date change problem. Even with this, 30% of its systems will not be compliant by January 1, 2000. (Anthes, 1996, Computerworld) In testimony to the House Subcommittee on Government Management, Information, and Technology on April 16, 1996, three government departments reported on the status of the Year 2000 Conversion project. The Social Security Administration began examining the problem in 1989. Mr. Dean Mesterharm, Deputy Commissioner for Systems, expects to have all conversions finished by December 31, 1998 so a full year is available for testing. This is despite his report that 30 million lines of software must be checked manually which could take 300 workyears. (U.S. Congress, 1996) The Department of Defense is dealing with some unique challenges in facing the Year 2000 problem. Partly for security reasons, their software inventory contains many uncommon computer languages, including Jovial. Software tools to help reduce the time to fix Y2K are available commercially for the most common languages, such as C, COBOL, and Ada, but not for many of the languages used by the Department of Defense. (U.S.Congress) In a poignant Memo to the Military dated March 31, 1997 and signed by General Dennis J Reimer, U.S. Army (available at http://www.year2000.com/archive/NFarmy.html) the critical nature of Year 2000 fixes regarding weaponry and automated tools in relation to the security and safety of both the military and the world are highlighted. The Y2K problem has become a "top priority." George Munoz, of the Department of the Treasury, addressed the complexity of dealing with non-compliant systems. Since not all systems can be updated at the same time, complex interfaces and configuration management will need to be incorporated. Bridges will have to be built between systems as changes are introduced. Firewalls and other protections will need to be developed as part of contingency plans to ensure the success of critical systems if interfaces fail. Comprehensive test environments will have to be built to ensure that applications can successfully process 21st century dates. (U.S. Congress, 1996) BUSINESS The banking and insurance industries have been working extensively on the Y2K project for some time. They are aware that if their systems fail, so could their businesses. However, all businesses are affected. Raising awareness is essential. The majority of businesses have not yet begun to investigate this in relation to their own companies. As happens with many overwhelming and potentially traumatic events, an early stage of reaction is denial. Over 5% of all businesses and 20% of all independent software companies are predicted to go out of business due to complications caused by the Millennium Bug. Even companies that achieve Year 2000 compliance on time are at risk from interacting with non-compliant systems. "Companies that still think the (year 2000) problem is contained within their systems organization are in for a rude awakening," warned Stephanie Springs, a senior systems director at Sears (Hoffman, Scheier, 1997) Shipping delays can cause loss of a market in the time-sensitive soft goods market. A coherent supply chain is vital. This emphasizes the international scope of the problem. In this global economy, no company works in total isolation. Companies such as Sears, Boeing, and Merrill Lynch and Co. are putting pressure on the companies with whom they do business to become compliant. On-site certification programs are being considered. (Hoffman, Scheier, 1997) LIBRARIES Accurate recognition of dates is important in most systems used in libraries. Serials, circulation, acquisitions, cataloging, statistics, payroll: each of these systems must be in compliance. Gina Smith (1997) imagines one scenario in her opening lines. "It's Saturday, January 1, 2000. Do you know where your library books are? You'd better, because they're a century overdue." In April 1997 the Library of Congress outlined its restructuring plan for LC Control or Card Numbers to accommodate the century change. While a detailed analysis of the Year 2000 changes needed is underway, an interim solution has been formulated. The Library of Congress began printing catalog cards in 1898. Two digits have been used to represent the year so the problem of distinguishing centuries begins in 1998! Although, for now both 1898 and 1998 will both look like "98-", each will be assigned unique Serial Numbers. (Normally, the same 100,000 Serial Numbers are repeated each year.) The long term solution involves expanding the year portion to four digits. The Library of Congress realizes that this change cannot be implemented without a thorough impact analysis of Year 2000 changes on all aspects of the data processing environment, so the exact date of this change has not yet been determined. For the full text of the announcement entitled "Library of Congress Control Number (LCCN) -- Restructuring to Accommodate Century Change," see: http://www.loc.gov/ marc/lccn.html. TESTING Validation of Year 2000 compliance is complex. Proper testing checks for correct recognition of centuries, years, leap years, days of the week, holidays, quarters, year ends, and more. (Ulrich, Hayes, 1997) A *preliminary* test on a standalone (after a complete backup) is as follows. Reset the clock to a couple of minutes before midnight on 12/31/1999. Wait a few minutes to see if it rolls over to 1/1/2000. Repeat these steps to check for proper recognition of the leap year. Set the clock to just before midnight on 2/28/2000 and be sure it rolls over to 2/29/2000. These tests should letting the clock run both with the system on and off. IMPACT ANALYSIS : MAKING A PLAN Before beginning a conversion program, a thorough inventory of applications and datafiles must occur. Identify the frequency of use of existing programs, as well as prioritizing their importance to continuing business. Then, determine the magnitude of the corrections needed. How many lines of code are involved? How many different applications are affected? How does your data interact with other systems, both internally and externally? Many vendors have arisen to assist with both planning, conversion and post-testing. Some offer software identification and software estimation tools. If the choice is made to go with an outside vendor, check their references first. Companies have varying degrees of expertise and reliability. Once the size of the project has been quantified, the incidence of Year 2000 references explored, and estimates made for repair, testing, and fixing "bad fixes", the project manager needs to set priorities. Which active applications are vital to fix before 1999? Which active applications must be replaced prior to 1999? Which active applications can be delayed beyond 2000? Which applications are dormant and do not need repair or replacement? (Jones, 1997) Due to the critical time element, the immensity of the project, and the reputation of Information Systems to be overworked already, it is regularly recommended that there be one full time person whose job is solely to coordinate the Y2K project. From all estimates, the work hours that it will take to complete this project on time is phenomenal. If a company has only 10 million lines of code, it would take 20 fast programmers working full time 2.5 years to finish find, fix and test code. A "fast" programmer can fix 200,000 lines of code per year. (Meta, 1997) COST To assist in planning, some costing must be done. Each year closer to 2000 gets more expensive, and it gets more difficult to find qualified people to accomplish the task. COBOL programmers are now worth around $100,000 a year. The cost of fixing each line of code has risen from $.50 per line in 1995 to $1-$2 in 1997. To put this in perspective, the Bank of Boston has around 50 million lines of code. (Appleton, 1997) Assuming a cost of $1.50 per line of code, that comes to $75,000,000. The Department of Defense has hundreds of millions of lines of code. (U.S. Congress, 1996) Peter de Jager, an international speaker on the subject of change and technology, writes on his Year 2000 web site that it is not unusual for a company to have more than 100,000,000 lines of code. (1997b) Converting the code is not the only cost of the project. Initial estimates of the project often take three to six months. Then the upgrading, data conversion and retirement of applications begins. Following that is the essential phase of testing, which can take 50% of the entire project time. An almost hidden cost is the stress factor. It has been very difficult to convince many CEO's that such a huge expensive project is necessary. For some companies, the decision may be made to shut down or sell some division of their company rather than cope with the challenge. Whatever the final decision, there is much support and knowledge available through numerous Year 2000 web sites, several comprehensive books, and a new Year 2000 monthly journal. Y2K listservs and conferences are two additional means for communicating with others working on the same problems. The positive side of all this planning, expense and conversion, is that the "new and improved" systems will be well understood and probably will function better than ever. THE FUTURE As the next few years unfold, research could be conducted on the accuracy of cost estimates, the success and failure rate of businesses, the number of programming languages (both known and unknown), the unexpected problems that arise in the course of this fix, and even the litigation suits that are being planned. There is no denying that the Year 2000 must be dealt with swiftly and accurately. In today's society which has come to depend on technology so heavily, we must accept the responsibility to become Year 2000 compliant. The financial burden must be borne while we prepare for success in the new millennium. References: Anthes, Gary H. 1996. "Feds face year 2000 crisis". _Computerworld_ 30(17):1,117 Appleton, Elaine L. 1996. "Call in the Cavalry before 2000". _Datamation_ 42(1):42-44 de Jager, Peter. 1997. "You've got to be Kidding!" http://www.year2000.com/archive/kidding.html first published January 10, 1997 (11 Jan. 1998) Efken, Charles. 1997. "Testing Year 2000 Compliance on the PC". _C/C++ Users Journal_ 15(4):68 Hoffman, Thomas and Scheier, Robert L. 1997. "Year 2000: the external threat." _Computerworld_ 31(9):1,16 Jones, Casper. 1997. "Year 2000: What's the real cost?" _Datamation_ 43(3):88-93 Kappelman, Leon A. and Cappel, James J. 1996. "Confronting the Year 2000 issue." _Journal of Systems Management_ 47 (4):4-13 Meta Group. 1997. "Year 2000 Scoreboard." _Computerworld_ 31(10):74 Smith, Gina. 1997. "The Millennial Mess". _Popular Science_ 250(2):26. Ulrich, William M. and Hayes, Ian S. 1997. _The Year 2000 Software Crisis: Challenge of the Century_ Upper Saddle River, New Jersey: Prentice Hall, Yourdon Press. U. S. Congress.1996. House. House Committee on Government Reform and Oversight: Subcommittee on Government Management, Information, and Technology. Panel Three's Testimony. April 16, 1996. *************** [updated and submitted to Associates on January 11, 1998 originally prepared for the class "Information Science and Technology", May 1997, University of Iowa, School of Library and Information Science]