Year 2k Bug

The well known Y2k problem might have been avoided had some
early people envisioned the degree to which the microprocessor would
change our lives. Surely, no one would have thought that in the early
days of ENIAC that everything from your alarm clock to your car would be
computerized. Even the IT managers of the 80's could not be blamed: The
disk space savings from dropping the two digits of the date over 100
Million Records would represent almost 200 Megabytes! Space requirements
aside, overhead on search times and disk loading/access are also added.Surely one could have designed a system whereby the program would be
aware of the century, regardless of the data records used. Hindsight is
always 20/20 however, and this was almost never the case.Regardless where you address the problem from, the year 2000 problem is
a huge, expensive and international one.

In many cases it is a problem
lined with doubt as to it's effects. This paper will analyze the various
aspects to the year 2000 problem, classical and software solutions to
the problem, and present the author's ideas on how a systematic approach
to the "millennia virus" can prevent doomsday from becoming a reality
for many information technology managers and their corporations.What, specifically, is this "millennia virus" to begin with? There has
been much talk about it, and most people know it has something to do
with the date formats and how the computer processes them. How it is
affecting that processing is what the key to implementing a solution is.

There are several forms the "bug" will metamorphose into.For example:Field / Date Processing
"Will all be affected by the problem? "OLD will seem YOUNG, a FEW
moments will seem like an ENTIRE century, FUTURE events will have
-- Duncan G. Connall; Global Software, Inc.The scope of this problem is immense. The awareness and information
available on this problem is growing rapidly, as a observation of the
rate at which the amount of information available on the Internet has
been growing. An advanced search of "year AND 2000 AND problem" through
the Altavista index yielded over 60,000 pages! Even this volume of
information does not sufficiently judge the magnitude of the problem.

Early IBM-PC machines and compatibles will be rendered useless for date
applications without running software patches as the system clocks on
the hardware level will not handle the four-letter date format.This problem is not only limited to personal computers and mainframes,
however. Most electronic devices that make use of dates will have
serious unpredictable problems. The micro controllers that are in car
ignition control systems, clocks, microwaves, and even nuclear weapons
all suffer from the same problem. The unpredictable effects come from
both the microprocessor used in the device and the compiler or linker
used to generate the code. As any programmer knows, when software is
given a input which it does not expect, anything can happen.

Anything
ranging from an error message to a serious program crash. The material
effects of these could be anything from your BIOS preventing your
computer from booting to your car not starting the morning after your
Strange effects have already begun to occur with many programs on the PC
platform not understanding the 2000-year field, or when it is entered,
defaulting to 00 or 1900. This is of particular concern with widespread
versions of home database and spreadsheet software becoming obsolete
unless patches are released to fix this behavior. For many companies,
however, the attitude has been to make a complete upgrade of the
software necessary - hardly an ideal solution for the home user.

"According to a variety of experts, it will take, on average, 6 months
to do and impact analysis of the systems before beginning another three
to six months worth of pilot projects. Then, production itself could
easily take a couple of years, depending on the size of your business
and the availability of resources. And those resources, whether in-house
or outside services, will become increasingly scarce as time runs out:
"We're telling people to book their services by the second half of 1996
-- Bruce Hall, IT Expert, January 1996 Datamation Magazine
Estimated man hour replacement costs for a large corporation
Comments Lines of Code Estimated Man Hours
Manufacturing System 1,200,000 2,000
COTS Software Provider 8,800,000 116,300
--Source: "The Millennium Mess" by CACI Incorporated
Several machines have already started to exhibit millennium bug. The
Unisys 2000, ironically named, uses a signed integer to represent the
8th bit of the year field, meaning that it failed on the first day of
1996. Several credit card systems have problems that cause cards entered
with a year of 00 to be designated as invalid. Some insurance companies
cannot sell 5-year annuities because their systems will not accept date
Hardware system problems have not gotten a lot of attention in relation
to the year 2000 problem, and their is little in the way of resources
available to determine if any particular system will be venerable to the
millennium problem at a hardware level.

There is another aspect of the year 2000 problem as well: Convincing IT
managers that they need to act in advance. There is a prevailing theory
that a "magic bullet" will appear to resolve the problems. All
indicators do not point in this direction. This problem is compounded by
the lack of professional resources available to deal with and repair the
problem.

Analysts estimate that resources should have been allocated in
most mid to large-size companies by the end of 1996. This point has
passed and still most companies have not acted.Part of this is that it is difficult to justify spending large amounts
of money just to remain in business. IBM estimates that they will need
to modify over 50 Million lines of code at an estimated cost of $20
Million dollars. The end result of which is to make the software work
the same on January 1st, 2000 as it did on December 31st, 1999.

The media is not helping matters, either. While almost everyone has
heard about the year 2000 problem, few people realize the potential for
disaster. The attention that the problem has received is minor accounts
of interesting "horror stories", mainly centered around inconveniences
The problem itself is deceptively simple: To the layman, it's only the
date. How much of an impact could the difference between 99 and 2000 be?
There has been no news coverage of a successful business going under
because of improper planning and preparation.

Those are the stories that
scare managers into allocating the resources that are required to deal
with the problem effectively. Unfortunately for most, those stories will
The degree to which most large computer systems are networked and
interdependent compounds all of these problems. Even extra-enterprise
systems can cause losses for a company; If your widgets need titanium
lugnuts and the lugnut supplier thinks that it's 1900, you won't be
getting any lugnuts and will be unable to produce widgets. Banking
systems are particularly sensitive to this kind of crash as there are
hundreds and thousands of nodes in their networks; Consider how many
Interact / Credit Card / Automated Teller systems are in place now! If
the software (or firmware) in any one of these systems is not working
properly it can cause problems anywhere in the network.These problems could range from money not being added and deducted from
accounts properly, problems with interest and financial forecast
situations, or even a complete crash of the network. Compounding this -
2000 is a leap year.

Some programs (Including Lotus and Lotus-Compatible
worksheets) do not recognize Feb 29th, 2000. (Datamation Magazine, Jan.The latter touches on an important aspect of the problem. There is no
definitive answer to a manager's question of "what will happen to my
program?" The all-encompassing answer is that it depends. Some operating
systems will default back to their creation date (1990 for MS-Windows
3.

1; 1980 for MS-DOS machines). Some programs will do the same, or
interpret the year as 2000. Others still will work sporadically and
output random data. Some will crash altogether. Some other applications
are based around a client server model. The server may be able to be
modified to cope with a larger year field, but the client programs,
often off-the-shelf, cannot be modified and in many cases are no longer
supported! The problem, then, is very subjective and ambiguous - there
"For once in our lives," says de Jager, "it doesn't matter the size of
the project, how many resources, how much money you have - the deadline
-- Peter de Jager, Year 2000 Consultant, quoted from Datamation magazine
There are several issues as to software and the insurance and the
potential liability for program failures of this magnitude.

One of the
questions that information technology managers are being asked about the
year 2000 situation is "who's to blame?". While this is a new occupancy
on the millennium bug field, and not much information was available, it
is conceivable that external contractors who provided software may be
faced with expensive lawsuits related to the inevitable failure of their
The insurance industry has already looked at the issue and determined
that companies will not be able to claim software failures (such as) the
millennium bug under most plans unless specifically defined, as it was
an intristic problem with the software and not something which would
have been unexpected and unavoidable. Programmers who have "professional
oversight or neglect" clauses in their consulting insurance plans may be
able to claim this, if sued. Affected corporations will no doubt be
looking into ways to assign financial liability to others, as a way to
defer what can be enterprise-crippling expenditure.While not a solution in it's own right, assigning blame and negligence
in this matter will be a part of a corporation's solution matrix,
especially if their development contracts for their software are clear
in this respect.

Other personnel which may be found liable for failure
to act could face being fired or disciplined - something which is also
just as sure to happen when upper management is forced to deal with a
large failure or shutdown caused by a failure to act on the 2000
"Gartner Group, Inc., an information technology research firm, has
estimated that it will cost between $300 billion to $600 billion to
correct the Year 2000 problem worldwide. "
-- Legal Issues Surrounding the 2000 Bug, by Jeff Jinnet
"The U.S.

Department of Defense, for example, plans to solve the problem
Possible Solutions to the 2000 Problem
The Key Solution: ISO 8601 Standard Date Formats. The real solution for
preventing this is to write software to standards. The wonderful thing
about the computer industry, it is said, "If you like standards, there
are a lot to choose from." There is, however, such a format.

The
International Standards Organization has a standard for the formatting
of the date and time for electronic computing devices. The objective
would be then to get the software compliant with this international
standard. If this had have been done from the beginning, there would not
be this dilemma. Indeed, the problem originates from programmers not
writing software to accepted standards, or even being aware that they
exist. Getting the software there, unfortunately, is the hard part.There is a need for this consistent adherence to the standard.

This
provides a means whereby the interchange of date information can be
facilitated between systems. Why is this important? Most computer
systems are networked and sharing information between many different
operating systems and programs through the use of common protocols, like
TCP/IP (Transport Control Protocol/Internet Protocol). Thus many systems
are sharing largely incompatible and/or incomplete (the source of the
The solution for this is to provide the complete date information in the
form outlined by ISO 8601. The implementation of this is quite simple,
and an OOP (Object Oriented Programming) approach is to define a date
class and use a date object to represent chronological information. An
example of this is the Java.

util.date class provided in the Sun
Microsystems JDK 1.0 package. This allows for all relevant information
to be dynamically shared between systems in a platform independent
In many cases, especially in larger corporations, it's not the program
that is the valued information: It's the data. These applications (large
mailing lists, financial information) open the door to a unique solution
that solves two of the larger problems at once. Writing plug in
enterprise wide replacements for the flawed application has two
2.

Offers the chance to enhance productivity through upgrading software
Allows independent startups to show up with "magic bullets" that IT
managers that are unprepared will be looking for at any cost towards the
end of the millennia. Unfortunately, it also has pitfalls: High R&D
cost. Whether absorbed by a independent software house or a client
corporation, such programs are expensive to develop on a large scale,
but will represent a large portion of the fixes for small Point-of-Sale
terminals and imbedded firmware applications. This high cost comes both
in the complex nature of the programs and the man-hours required
developing these solutions. High implementation cost. Unless over a
large scale, the research and development expense will be recouped at
This is the solution being implemented in corporations with large IT
sections and has some plan in place.

Through re-engineering their
existing source code they can develop applications that support the 2000
format. At the same time new features can be added and the source can be
recompiled to work under improved hardware. Like any other approach, it
has its benefits and pitfalls. This approach makes use of existing
source code, and where compilers are available and supported it can make
in-house expertise with that source code. Source conversion products for
several mainframe languages such as COBOL and Assembler are becoming
available. While these are part of the solution, a lot of code
manipulation is still required to make the product work as expected.

While such programs can handle programs that get the date from the
operating system, they cannot handle areas where the date is an integral
part of a numerical algorithm. This problem still requires analyzing the
code by hand and often requires less external assistance and support,
leading to a much cheaper solution for companies. This solution requires
a significant amount of planning in advance and is often not practical
for many ventures that haven't begun their 2000 conversions.Some hardware systems are the problem in that the date they provide from
the hardware will not be functional after the year 2000, or before. IBM
has announced such patches for its S390 processor machines running VMS
5.1 or later.

Intel based personal computers that do not support the
2000 format in their BIOS will have a real problem in that they will
require a DATE command to be entered very time the machine is turned on!
This is not a practical solution for applications that require
organization around dates - what if an operator forgot to enter the date
The software patches to hardware are a "quick fix", that will require a
hardware (firmware) upgrade. The market for such BIOS chips is sure to
grow exponentially fast after 2000 has passed given the millions of
these machines in service. IBM PC's manufactured before 1996 (all) will
have this problem. IBM has since promised that all machines shipped
after 1996 will function properly after 2000. Hardly the ideal solution.

(Jan 1996 Datamation article by Joe Celko)
The System is the Solution: Solving the 2000 Problem
For most companies, the solution will involve a combination of the above
strategies. How they will be implemented, and whether or not they will
be in-house, contracted or some combination thereof will dictate a
The first problem facing the IT manager in charge of developing a
strategy to have their company undergo a smooth transition past 2000 is
to determine what their problem is. How much of their software will be
affected? What will be the consequences if no action is taken to resolve
the problem? Is their centralized database software capable of the
change? What about client applications?
These are only some of the questions that must be answered. Once a
reasonable estimate of the scope of the problem that must be dealt with
has been obtained, an assessment of the problem can then be made.Specifically: Is it cheaper to repair or replace the system?
There are several factors that must be considered here.

If you are
dealing with a mainframe computer, is the source code still available,
and if so, is there a supported compiler that does not suffer from any
inherent 2000 problems? If this is the case, do you have the people that
can modify the code in house, or if not, do you know that adequate human
An analysis of the expenditures and benefits to repairing the existing
system may lead you to the conclusion that replacing your system
altogether is a more attractive option. This step requires a great deal
of planning and foresight. If your system is seriously affected,
replacing your existing processing applications with new ones that can
convert your old data may be an appropriate decision to make.What are your suppliers and customers doing? If your systems are
interdependent, then you need to agree on a format and a course of
action. Using independent standards is the obvious intelligent choice,
but whatever format that is agreed upon it must be implemented by all
parties that will have systems affected by your own in-house changes.Develop a Strategy for Deployment and Testing
Once you have committed to a plan of action, there needs to be a
schedule for deployment and testing of the new system.

There is no way
that the deadline can be extended - regardless of your resources, you
must be running when the Jan 1, 2000 clock rolls over, or there will be
The year 2000 problem is the kind of programming project, which is
typically subject to delays, and setbacks - characterized by serious
time constraints, broadly defined scope and inter-compatibility
problems. Many sources recommend that a separate project manager with
experience in these kinds of applications be hired to assist in the
timely completion of your plans. This project manager should preferably
have experience in dealing with year 2000 conversions, but as many
companies are finding out, such experienced personnel are few and far
Testing of the software has it's own unique problems and difficulties.Not only must you make sure that the software works with post-millennium
code, but it must work with prior code and data alongside. This process
is very time-consuming and where parallel testing equipment is not
available (most cases), a large component of the testing will have to be
carried out by hand, a time-consuming and error-prone process.

"Systems must be well tested to ensure that functionality has not been
changed in any program as a result of the date changes. This means a
unit test of the program, a system test with a test bed of data covering
all functions, a simulation test to any date in the future that may
impact your system (this involves moving your data and your system date
into the future), and finally, a test with historical data to make sure
you can process old data through the system once changes are complete.Developing a test bed for these changes is a significant task. The
testing stage represents 40% of the effort for the entire project.

"
-- Brenda McKelvey, from a report on the "Year 2000: Blueprint for
Success" conference in Orlando, Florida, November 1995; Datamation
No doubt about it - this is one project that is going to be extremely
expensive for some companies. Whether it is money spent on converting or
re-engineering their computer systems, or money lost on downtime caused
by millennium bugs, the projected figures are enormous. Where will you
get the financial resources to make the conversions? If you have been
planning all along, then you have already established a fund that can be
drawn off for consultation and implementation of the bug fixes. If not,
you will have to look into where resources can be drawn from to fully
implement these changes before downtime starts costing you money.

If your company had software developed that suffers from your spec, was
inherent system failure written in the development contract for your
systems, and if so, is legal action a possibility to recoup some of the
costs associated with re-engineering or repairing your computer network?
Start implementing your plan of action. The nature of the repairs and
replacements are extremely time critical, and planning with regular
progress meetings and code reviews should be undertaken to help assure
that you are on track to staying on line throughout the next millennium
- or at least until the next software upgrade.An Example: Case Study - MicroCorp Widget Producers, Inc.Scenario: A small corporation, utilizing customized PC based sales
software for Windows 95 and a larger, custom programmed
database/retrieval system (old).

This larger system talks to their
supplier's computer to automatically ship source materials when they are
low. The solution for Microcarpa Widgets is multi-faceted. Starting off
on a checklist: Testing their PC's to determine if the BIOS will support
the year 2000. Without this, all their software will report incorrect
dates, including the operating system. Analyzing their sales software to
determine if it will handle the year 2000 correctly.

Provided source
code is available, the manipulation of the software to support the date
format that is settled upon (IS 8601, of course.) should not be a
difficult task. If source code can not be obtained a re-write will have
to be performed. Talking to their suppliers to implement a IS compliant,
or mutually agreeable, standard so that normal business particles will
not be upset.

Looking at their mainframe situation to determine if there
is source code and compatible tools and compilers available. If so, are
the programmers available to make the conversion a reality? Would moving
to a more modern, more flexible system be an attractive move to make?
Will it be a necessary move? On the basis of this impact analysis,
develop a concise and clear strategy for moving their company on to
Even a common setup like this has many potential problems and can be a
very expensive one, especially if it is not handled properly &
efficiently. The biggest problem that this widget producer will have is
convincing its managers that there is a problem that needs to be
The one thing that this paper needs to demonstrate is that there is no
silver flyswatter to kill this bug with for most medium and even small
enterprises. Any corporation with in house software developed to handle
inventory or database control will almost inevitably have to deal with
this on some level which will involve a re-engineering or replacement
situation, and will probably be very costly in terms of both dollars and
man hours, and could be even more costly in terms of potential downtime.This is further compounded by the magnitude of the problem - there will
be a worldwide shortage of people to deal with this problem.

The only solution that will work for most is a multi-faceted one. The
strategy for dealing with this problem must be well laid out well in
advance, and must be implemented before the absolute deadline of
01/01/2000. Many information technology experts have already said that
this deadline has in fact already passed and managers should now be
looking at plans, which will include ways to minimize downtime at the
From the entrepreneur's perspective this is a time which is full of
opportunities. There are several key applications which could be
developed as "plug and play" fixes, making use of existing data formats
for conversion and implementing a system which repairs the date problem
and adds functionality or speed in the process.

The sheer magnitude of
the effects will make the upcoming years very interesting in the
information technology field. One thing that everyone can be sure of -
there will be a swift judgment of your preparedness on December 31,
Bibliography:
"Legal Issues Surrounding the Year 2000"
Author: Jeff Jigget
http://www.year2000.com/archive/
"ISO 8601 Standard for Numerical Representation of Dates"
International Standards Organization
http://www.cl.cam.ac.uk/mgk25/
"Year 2000 Issues List"
Serge Bouwens, PTT Telecom, Netherlands
http://www.year2000.com
"The Millennium Mess"
CACI Incorporated
http://www.caci.com
"Experts Call Year 2000 Bug a Real Threat"
Reuters News, Inc.http://www.reuters.com/
Datamation Magazine
http://www.datamation.com