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]