ASSOCIATES (vol. 4, no. 3, March 1998) -

Table of Contents


                     *YEAR 2000 DATE CONVERSION: 
                         AVERTING THE DANGER*


                               Mary Iber
                      Specialist II at ACT Library
                        with specialty in Serials
                            Iowa City, Iowa


	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.


	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. 


	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 


	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)


	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 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)


	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)


	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:


	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.


	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)


	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.


	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.


Anthes, Gary H. 1996. "Feds face year 2000 crisis". _Computerworld_ 

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!"
 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_ 

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]