Steve's Home Page - Contact info / About Author
Don't let another design problem happen to your enterprise again. Run Linux and promote open source code & open design solutions! You have nothing to lose but your chains.
Forward: I took this down after the transition went much smoother than expected. I didn't expect the demand that this page had generated, so I decided to leave it up for posterity. Enjoy.
Check out my Y2k survival ammendum at the end of this document for some of my "worst case" suggestions. While I'm not so "get guns and live in the desert", a la the August 1998 Wired, some preparation might be in your best intrest.
The year 2000 problem could have been completely prevented 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 they
are processed by the computer. 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:
Could all be affected by the problem.
"OLD will seem YOUNG, a FEW moments will seem like an ENTIRE century, FUTURE
events will have ALREADY occurred."
-- Duncan G. Connall <firstname.lastname@example.org>, Global Software, Inc.
Scope of Problems
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 60000 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. On the PC level
this is easy to test; Just advance your clock temporarily. With a mission
critical mainframe, this becomes much more difficult.
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 sed in the device and the compiler or linker used to generate the
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 millennium party.
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 at the latest,"
-- Bruce Hall, IT Expert, January 1996 Datamation Magazine
Estimated man hour replacement costs for a large corporation
|Comments||Lines of Code||Estimated Man Hours|
|COTS Software Provider||8,800,000||116,300|
|401k Plan System||12,000,000||200,000|
Source: "The Millennium Mess" by CACI Incorporated
List of Problems
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 entries past 1999.
Hardware system problems have not gotten a lot of attention in relation to the year 2000
problem, and there 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. Mainframe
equipment is expensive and/or impossible to take offline, and in some situtations
this is the only technique to determine if a failure is emminent.
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 (see figure). If you're having problems filling technical positions now, concider what your position will be after serious problems develop.
Another issue is that the software "fix" for the problem is not enough; Any changes
must be tested and verified. This is hard enough when deadlines are flexible.
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 which the
problem has received is minor accounts of interesting "horror stories", mainly centered
around inconveniences and program failures. What about when the power grid fails?
The problem itself is deceptively simple: To the layman, it's only the date. How much of an impact could the difference between 1999 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 which are required to deal with the problem effectively. Unfortunately for most, those stories will not happen until it is far too late. More common is "disaster" planning amoung upper executives than actual Y2K compliance. What are you going to do when your suppliers fail to deliver on schedule?
Networking: Multiplying the error
All of these problems get compounded by the degree to which most large computer
systems are networked and interdependent. 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 as a valid
date. (Datamation Magazine, Jan. 1996 Joe Celko) This would render most financial
macros for these programs useless without modification.
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 Microsoft 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
The problem, then, is very subjective and ambiguous - there will be no quick fix.
"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 is fixed."
-- Peter de Jager, Year 2000 Consultant, quoted from Datamation
Legality - Paying the Bills
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 software. While some
professional contracting agreements and liability insurance make this clear, many
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 disiplined - 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 problem.
"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 at a cost of $1.1 billion. "
-- Reuters News, April 7th, 1997
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. (Authors note: this is a seriously
lacking area in undergraduate Computer Science and Engineering programs today.)
Getting the software there, unfortunately, is the hard part. Many professional
programmers and software engineers are unaware or unwilling to write to standards,
and marketing and management departments are unwilling to act until customers
start to demand said functionality.
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 2000 problem) date
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 manner.
Local Fixes: Saving the Data
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 benefits:
Unfortunately, it also has pitfalls:
In House / External Re-engineering:
This is the solution being implemented in corporations with large IT sections and have
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 it's benefits and pitfalls:
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
it's 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 some Monday morning?
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 companies year 2000 strategy.
Assess & Identify
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 concequences 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 which 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 resources can be found?
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.
Communicate with Business Partners
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.
Even if you do not share computer systems, such as accounting or just in time
delivery methods, then you need to make sure that your suppliers will be
able to meet delivery contracts and obligations. You would be advised to
secure delivery schedules in writing. You might be suprised to find out
how reluctant your partners may be to provide such guarantees.
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 January 1 2000 clock rolls over,
or there will be losses to account for.
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 between. Compounding this problem is the explosive growth of the software industry in the US, making software engineers and other computer professionals difficult to hire and even more difficult to keep.
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, expensive 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 <email@example.com> from a report on the "Year 2000:
Blueprint for Success" conference in Orlando, Florida, November 1995
Allocate Financial Resources
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 differs 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? Legal advice should conditute a signifigant part of your "disaster plan".
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. Take the opportunity
to engineer your systems properly, and remember my fundamental rule: A sign of
a good design is that changes are not difficult, painful, or expensive.
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
The solution for Microcorp Widgets is multi-faceted. Starting off on a checklist:
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 it's managers that there is a problem which
needs to be investigated.
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
The only solution which 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. 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 turn of the
millennium. Many companies which I have spoken to have already acknowedged this and
are proceeding with impact studies.
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 judgement of your preparedness on December 31, 1999, 23:59:59.99.
Afterword: Y2K Survival
The current state of preparedness, or, should I say, unpreparedness in the United States and Canada is very disturbing to me. Not much has happened since I wrote this paper almost a year and a half ago! The sad thing is that the North American markets are amoung the best prepared. What about all the other countries of the world with electronic systems? What about the state of asia? Third world countries? The degree to which this is being underestimated is *shocking* to me.
With these facts in hand, what is a worst case senario for most people? Commoditity shortages should be taken into account and prepared for. What does this mean? It's probably a good idea to stock up on stuff you're going to use anyhow - food, cleaning materials, etc. This isn't what worries me though, although, I'll be buying my school term ration of Kraft Dinner as usual :).
What does worry me, you ask? It's losing electrical power. No power means none of this can get fixed, and that is going to mean a REALLY big mess. How can the power you go out, you may ask. It's actually fairly simple. If one or two major plants in the US were to go offline, major stress would be placed on the North American electrical grid. This could cause unpredicable effects. Supply trains to power plants could be affected by the Y2K problem, oil delivery schedules could get messed up, and the worst one of all, automated embedded circuitry can fail, especially critical checking circuitry designed to prevent a disaster with a plant. The good news is that it will preventively fail - nothing will happen. Of course, no power will be produced either. This will take time to fix. National Semiconductor and Motorola, major embedded chip producers, will be good stock bets. The stock market is one of the few entities which will be prepared. And don't get your hopes up; So will Visa.
People forget that cars are good emergency generators, although impractical for large amounts of time. It might be a good idea to keep your tank filled and perhaps invest in a couple tanks worth of storage in gasoline - you'll use it anyhow. A solar panel and some car batteries can keep you in touch with the rest of the world, too. I'll be posting some charging, voltage inversion, and other useful circuits soon. Never forget knowledge is power :). And you can give me all those solar panels if you don't use them. They're cool.
In other words, there's no reason to go crazy, but there is reason to expect that things could reasonably be distrurbed from their normal routine. I don't live in a major city, either, so riots aren't an issue for me. I have no desire to live in a major city either, and you couldn't pay for me to work in one right around the time of this. Insurance doesn't cover riots, either.. :) I wouldn't want to be in LA if the power was out for a week. Don't worry, be happy! :)
As a upcoming Computer Engineer, I can definately look at exciting times ahead in the next few years. I might even be able to work myself out of debt, but, for the record, I haven't made so much as $0.01 off related Y2k issues, this paper included.
Web Pages and Web References
"The Millennium Mess"
"Legal Issues Surrounding the Year 2000"
Author: Jeff Jigget
"ISO 8601 Standard for Numerical Representation of Dates"
International Standards Organization
"Year 2000 Issues List"
Serge Bouwens, PTT Telecom, Netherlands
"Year 2000 Frequently Asked Questions List"
Maintained and edited by Robert J. Sandler <firstname.lastname@example.org>.
"Experts Call Year 2000 Bug a Real Threat"
Reuters News, Inc.