Summer 1996 Articles

Disaster Recovery Journal

Volume 9, Issue 3
Summer 1996

The Disaster of the Century
The Year 2000
By Donald Fowler

The disaster of all disasters is awaiting all companies at the end of the century. It is pervasive in all technological solutions being used in day-to-day business. Many experts have called it “The Year 2000 Virus”; others are calling it “The Millennium Crisis”. Whatever name is used, the results are the same. Possible business cessation, lost clients, reduced revenues and tremendous amounts of staff rework time can and will occur when the clock strikes midnight on December 31, 1999. This disaster scenario will occur worldwide for companies that have not taken prior steps to avoid it.

So, what is this doom awaiting us all? Very simply it is that almost all computers have relied on a two-digit representation of the year. Thus, come the year 2000, this representation will be “00”. The computer will:
•attempt to compare current system date “00” to previously stored dates and determine that the new year is less than the previous. (After all “00” is logically less then “99”, isn’t it?)
•attempt calculations that will fail for this same reason. The classic example used by Year 2000 experts is that of the computer determining someone’s age. (Using the author’s birthday as the example, the stored birthday value would be “45” for 1945. The system would subtract that date from the current system date “00” and determine the age to be 45 instead of 55.)
That is the crisis. Computer technology and programs will make incorrect calculations and comparisons. Oh, by the way, there is one additional twist in this. Most date handling routines used in many hardware and software products incorrectly handle the year 2000 as a non leap year. So, as of midnight February 28, 2000, many computer dates will incorrectly indicate March 1, and not the correct February 29, 2000.
This problem exists across and includes all business solutions technology utilizing computer chips. The Year 2000 problem lurks from the personal computer on the desktop to the departmental servers and largest mainframe systems and even to the phone and security systems.

Hardware: Built-in Obsolescence

The least discussed problem facing companies in this impending crisis is the possible obsolescence of existing hardware platforms. Take the case of the millions of personal computers used in business today. If a company has not added a year 2000 compliance clause in its purchase contracts, vendors may still be shipping hardware that will not operate properly in the year 2000. There are widely known problems with many Basic Input Output Systems (BIOS) within the PCs that cause the machines to be unable to recognize the year 2000. There is a simple test for this that should be performed on every PC within your company. Set the date to December 31, 1999, and the time to 23:59:00. Turn the machine off and back on. Then issue the date command or query the system date. A very large percentage of the currently installed PC inventory will indicate the system date as either 1980 or 1984, not 2000! These machines contain BIOS and time-of-day chipsets that are not year 2000 compliant. A formal review process must then be performed to which determine applications running on these machines will be impacted by the bad system date. A decision must then be made to repair or replace the offending hardware. This can become an incredibly expensive project. Some similar technique must be performed against all other technology-based business equipment. The technology vendor should assist in determining the testing technique to use or indicate if the technology is already year 2000 compliant.
A suggested enterprise-wide action is to send a letter to each technology vendor and ask for:
• a statement of year 2000 compliance
• the vendor’s repair plan if not in year 2000 compliance
• the target date of any necessary repair(s)
• the possible cost to your firm for repair(s)
These responses should be in writing.
A quick word on mainframe obsolescence. Many older generation mainframes will not be provided with repair actions and thus operators will no longer be able to reset the time-of-day clocks after 1999. Several large mainframe vendors have already notified customers of this. Be aware that your existing computer complex may be functionally obsolete in a few more years!

Application Software: The Disaster Continues

The hardware issue is just the tip of the iceberg. What about the billions of lines of application code used in supporting business functions today? These too have implemented, for the most part, the two-digit year representation. Year 2000 vendors have developed and are continually developing new source and object scanning tools to inspect a company’s entire application inventory to determine date impact problems. If this analysis has not yet begun in your company, you are truly running out of time. Without knowing how many programs are in trouble, a reasonable, well-thought out plan of attack (i.e., the project plan) cannot be established.
This analysis phase becomes elongated as more computing platforms are involved. The use of Client/Server applications in many cases spans three or more separate and unique computing platforms and uses four to six software languages. Many companies have little inventory and configuration control in the distributed environment. The human resources needed to perform the inventory and tie desktop, server, and mainframe executables into a coherent picture can be costly and lengthy.
The well-known year 2000 speaker Peter de Jager stated that well over half of all companies in the United States will not be ready in the year 2000, due mostly to a lack of management interest or concern. Not being ready could mean that only some of the business applications are compliant. In your company, which applications will these be?

The Cost Equation

The sheer size of identifying, repairing and testing all year 2000 related defects is staggering. The latest estimates from the Gartner Group is that this problem will cost $300 to $600 BILLION worldwide. Many large enterprises have already received estimates of over $100 MILLION to resolve their problem.
This problem is the first in computer technology history that has a final, pinpointed drop dead date that cannot be avoided. Project slippage cannot be tolerated nor can it be “swept under the rug”.
The worst effect for every company is that this project has no return on investment, no increased competitiveness, no increased productivity and no upside (unless you consider staying in business being the upside). This is a pure expense. However, this expense is almost identical to all other expenses incurred related to business continuity and business recovery. Thus, those who are business contingency planners can apply the same techniques to solving this impending disaster as done today for other disaster conditions.
As an example, is an application system that is providing wrong answers, wrong reports and corrupting stored data files any more available than an application system completely down due to a natural disaster? If the answer is that a defective system is as bad as a totally down system, then you immediately have hard dollar numbers from your Business Impact Analysis that can be applied. Even if the answer is “Well, maybe it is 50% as bad as being totally down”, you still have hard dollar numbers. These numbers become extremely meaningful to determine the cost of the benefit associated with the identity, repair and test project costs. Your BIA may well point the path for the schedule of what applications need to be repaired in what order.
Remember that it will take time to perform the activities to find the bad dates, repair the dates and the program logic and test the repair. Large applications can take three to nine months to complete. Can your organization survive when a critical application fails on January 1, 2000 and it will take nine months to fix it? Or even three months? Probably not.

Contingency Planning
For the Year 2000
The best contingency plan available is to avoid the disaster condition. You formulate such disaster avoidance plans today. This disaster is no different. To avoid the disaster, a comprehensive, formal and detailed plan of attack needs to be in place and executed in a timely manner to identify, repair and test the business functions well before the year 2000.
A recent IBS Conversions’ white paper, “The Year 2000 Repairs: Cost Savings Ideas,” discusses some ways to shave costs and time from a year 2000 compliance project at acceptable levels of risk. These areas of risk assessment need to be handled by personnel who live with such risk assessment day in and day out; that is you. You need to take an active role in determining how your company will deal with this impending date issue. Apply all of the expertise, skills and techniques you have to assist your user groups and Information Systems professionals in formulating the disaster avoidance plan and gaining executive commitment to the cost of implementing the plan.

Donald R. Fowler is currently Technical Strategist and Conversions Architect for several Year 2000 projects. Mr. Fowler has over 29 years of experience in Information Systems.

|Return to the Summer 1996 Index | Send Email to DRJ |

Webmaster---Robert Arnold

Last Updated--Tuesday, July 16, 1996.