Steve's Home Page - Contact info / About Author |
Numerical Methods in Java - Back to the CS3113 Main Page |
Forward: I had no idea of the intrest/traffic that this page would generate. If you'd like to discuss anything in here further please email me, especially if you are using Java as part of your year 2000 solution! This term paper was originally written to complete a course requirement and is part of the Numerical Methods in Java page.
Warning! Recently a unethical and immoral student attempted to steal my writing here and pass it off as a term paper, and got *caught*. I hope that this will serve as a strong reminder to him and others to respect intellectual property, graciously provided free here on the internet. If you wish to use my paper, please quote, not steal, and provide a simple reference crediting me. Thank you.
Introduction
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 "millennium 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:
"OLD will seem YOUNG, a FEW moments will seem like an ENTIRE century, FUTURE
events will have ALREADY occurred."
-- Duncan G. Connall <dconnall@tiac.net>, 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.
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 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 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 |
Manufacturing System | 1,200,000 | 2,000 |
COTS Software Provider | 8,800,000 | 116,300 |
Commercial Software | 2,000,000 | 2,500 |
2,000 Programs | 7,000,000 | 38,000 |
Retail System | 1,300,000 | 9,000 |
401k Plan System | 12,000,000 | 200,000 |
Totals: | 39,800,000 | 442,800 |
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 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 (see figure).
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.
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 which are required to deal with the problem effectively. Unfortunately for most, those stories will not happen until it is too late.
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. (Datamation Magazine, Jan. 1996 Joe Celko)
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 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
magazine
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.
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.
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 information.
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:
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.
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 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.
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
beenchanged in any program as a result of the date changes. This means
a unittest of the program, a system test with a test bed of data covering
allfunctions, a simulation test to any date in the future that may impact
yoursystem (this involves moving your data and your system date into thefuture),
and finally, a test with historical data to make sure you canprocess old
data through the system once changes are complete. Developing atest bed
for these changes is a significant task. The testing stagerepresents 40%
of the effort for the entire project."
-- Brenda McKelvey <mckelveybj@em.agr.ca> 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 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?
Take Action
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.
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:
Conclusion
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 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 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 turn of the millennium.
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.
Bibliography
Web Pages and Web References
"The Millennium Mess"
CACI Incorporated
Email: webmaster@hq.caci.com
"Legal Issues Surrounding the Year 2000"
Author: Jeff Jigget
http://www.year2000.com/archive/NFlegalissues.html
"ISO 8601 Standard for Numerical Representation of Dates"
International Standards Organization
http://www.ft.uni-erlangen.de/%7Emskuhn/is-time.html
"Year 2000 Issues List"
Serge Bouwens, PTT Telecom, Netherlands
http://www.year2000.com/archive/issues.html
"Year 2000 Frequently Asked Questions List"
Maintained and edited by Robert J. Sandler <rsandler4@juno.com>.
"Experts Call Year 2000 Bug a Real Threat"
Reuters News, Inc.
Usenet:
comp.software.year-2000