Solving the Year 2000 Dilemma

Solving the Year 2000 Dilemma
by James Reed, Kaman Sciences Corp.

You have heard about the computer systems and software problems involving the year 2000 haven't you? Do you know the extent of the problem? Do you know how it will affect your organization? Do you believe it? Does your management believe it? Do you have a plan in place to solve the problem? Are you working the problem now? Do you know where to get help and more information?

What's the Problem?

Back when code was tight and memory was scarce it became a standard practice to abbreviate date code within software as mm/dd/yy. Note the two places allocated for the year designation. That worked just fine till recently. Unfortunately we now understand that as we head toward the end of this century we'll see massive failures of software and systems. They will fail because when the clock rolls over at midnight on the last day of December 1999, the computer won't know the correct date. It may indicate the year is 1900 or it may pick some other year. In software and system assessment tests, the years 1980 and 1984 are popular. If you have any programs that do date-time projections and incorporate some hashing and random number generators that use parts of the system date, you'll have a problem when your program attempts to divide by zero and your program crashes - repeatedly.

Another problem surfaces because when a number of programs were developed, the programmer didn't always understand that the year 2000 is a leap year. In grade school we all learned that each year actually consisted of 365.25 days and to account for the fraction, every four years we tacked on another day, February 29th. Some of us also learned that there is an exception to that. If the year is the first year of a century, say 1900 as an example, then it is not a leap year. Who remembers that there is an exception to the exception? If we hadn't played hooky that day to play stickball, we would have learned that if the first year of a century is divisible by four (for argument's sake, let's use the year 2000 as an example) it is a leap year. You can appreciate the magnitude of miscalculations when your software and system can't correctly determine time. If we're lucky and the problem is not corrected the program will simply crash. What happens when the program continues to operate and the operators fail to note the errors until after thousands of dollars of interest or payments are lost?

There are other problems too. There are the "year-in-century" problems. What happens when you want to arrange for a 15 year home owners loan. You set it up in 1996 for payoff in 2011. However, if you subtract the two year-in-centuries, using the existing two-place year representation, the calculation is 11- 96 = -85. That is truly an early payoff schedule! What if you are working with large stocks and inventories? Your system may tell your people that the shelf life of items has expired and they may dispose of perfectly good, high cost items, just like the computer told them to do. Will you catch the error in time? These problems are just the highlights. There are more, like systems interpreting 99 as łend of file˛ and stopping your processes. Or it might look at 00 as a null value and sit in limbo waiting for you to tell it to do something.

If uncorrected, the costs to business, industry and defense will be astronomical. Already it has been estimated that the cost to correct the millennium date problem will run somewhere between $300 billion to $600 billion, with some estimates placing the cost at over $1 trillion worldwide. Some estimates put the cost of taming the Year 2000 compliance beast for the US Federal Government at somewhere in excess of $25 billion. The costs are so high because the date problems are pervasive. Greater than 90% of all software programs will be affected. Depending on software programming complexity, integration, and interaction with other modules and systems, cost estimates range from $1.00 per line of code to over $8.00 per line of code for the more dedicated, esoteric sorts of applications - like those in embedded defense systems. In general, from 1 to 5% of code may be date involved. You'll have to arrange to check it all to make sure you haven't missed any lines. Certainly that percentage can be higher when dealing with business software which deals with costs, schedules, inventories, and the like. By the way, we're not just talking about software here. There are a lot of embedded chip sets with the two-place date schema hard coded. Those legacy systems with affected chips will have to be remanufactured or the systems may have to be scrapped. Bridges and routers anyone? How about all those personal computers in the work place and all of the non-compliant software in use?

Many systems and software packages will have to be updated and replaced. Anyone running a network? Anyone have archives? Do you have legacy data? Anyone doing work on a home system and uploading their data to the office system?

What Should I Do?

First, brief the top echelons of management about the problem and the imperative for immediate action. The drop dead date is fixed. The year 2000 will be here whether or not you are ready. Recognize that you must start work to determine the extent of the problem within your organization and then work to correct it. In large measure, bringing your systems and software into compliance for the year 2000 is a complex program management task. You will have to determine whether you can do the work in-house or whether you will need to out source some or all of the work.

The steps are as follows:

All software and hardware will have to be inventoried and assessed to determine the extent of the year 2000 problem within your organization.
Develop an action plan which permits you to be ready to test your systems and software starting no later than 1 January 1999. We strongly recommend you prioritize your compliance initiatives so that mission essential systems are identified, assessed, fixed and tested first. For many of you who have not already started the process, there is no time to waste on pilot studies and demos. You must act now.
Renovate, modify, replace or make a decision to scrap existing systems and software based on your mission and business priorities and take action.
Test and validate the changes over as long a time period as the magnitude of your effort permits. Since reaching 1999 may cause a number of failures from unmodified code and systems, your plans should include testing and modification during 1999.
Implement any corrections based on the results of your tests and validation. Make sure you make education a part of your plan so that well-intentioned organizational members don't load corrupt data into tested, compliant systems from non year 2000 compliant systems.
Do some contingency planning. In all likelihood, "Murphy's Law" will apply during your work on this task and things will go wrong at the worst possible time. Priorities will change, staff changes may impact your efforts and the funding picture may at best be a moving target.

Can the DACS Help?

Yes. We are gathering information concerning the year 2000 problem, tools, methods, testing measures, vendors and compliance program experiences. We will provide information through the DACS Newsletter, our web page and other methods as necessary. We will assist you in defining the problem to top management and explaining it within your organization. Members of the DACS staff will also work with you to conduct an inventory, assess your year 2000 compliance problems, effect solutions, and test corrective measures.

For further information check the DACS Topic Area New Millennium: The Year 2000 Problem or to discuss arranging for DACS assistance via a Technical Area Task, contact:

Elaine Fedchak - DACS
Y2K Project Leader
775 Daedalian Drive
Rome, NY 13441-4909
Telephone: (315) 334-4900
Fax: (315) 334-4965
E-mail: [email protected]