Technical overview of the year 2000 problem

I.

INTRODUCTION

In precious little time we enter a new century. Whether our computer systems enter the same century intact depends on corrective actions that should already be well underway within corporations and government agencies. If these entities do not make the proper corrections in time, those same computer systems will likely reenter the twentieth century - and not the twenty-first.

The Year 2000 computer problem has quickly redefined the agendas of virtually all information systems ("IS") organizations. What was first considered to be a significant computer maintenance problem has also bubbled over to become a management issue - and it certainly will become a legal issue as well.

Simply put, the Year 2000 computer problem revolves around the manner in which date data is stored and manipulated within computer programs. For the last thirty years, it was common practice to store a date value using a six-- digit numeric field, with two digits representing the year, two digits representing the month and two digits representing the day of the month. For example, the value 970723 would represent the year 1997, the month of July, and the 23rd day. Storing date data in this manner has several inherent advantages. First, it conserves memory, a computer resource considered all too scarce until just recently. In addition, this form of representation facilitates both logical and numeric processing of date data. The inherent weakness of this data format, however, is that the implied century value is always assumed to be "19." Hence, when the year changes from "99" (1999) to "00" (2000), many computer programs will process date data values as if they were occurring in the 1900's.

Unless corrected, the Year 2000 computer problem will affect the processing of programs in three areas. First, in programs that sort date applications (i.e., reports and displays), data that represents values in the twenty-first century would always be improperly sorted. For example, assume that the following represents year values (and that 00 represents 2000): 89, 76, 97, 00, 92. If the data is sorted from the oldest to the most recent (i.e., smallest number to largest) then the resulting sequence would be: 00, 76, 89, 92, 97. Rather than assigning 00 as the year 2000, the program believes 00 is the significantly smaller 1900. A similar problem occurs if the data is sorted from the most recent to the oldest.

Secondly, when used in calculations, date data can produce spurious results. For example, assume that the number of years is to be determined between 00 and 53 (i.e., the years 2000 and 1953). The resulting value would be 53, rather than the correct value of 47. Mistakes like these could be significant when the results are used to determine the age of individuals for certain types of insurance eligibility or coverage.

Third, if dates are used in logical processing (e.g., determining if a date has exceeded an expiration) the wrong conclusions can be reached. For example, the value "000421" (April 21, 2000) could conceivably be considered less than "970723" (July 23, 1997), and the time limit already expired. Mistakes like this could keep products like drugs from being placed on store shelves.

In each of the foregoing examples the processing is not interrupted, but the results are wrong. Detecting and correcting these types of errors are what make the Year 2000 problem so complex. Unless "fixed," date processing mistakes have the real probability of impacting the delivery of utility and banking services, corporate processing, and government functions, to name but a few. In fact, even if an organization is capable of remedying its systems and "cleansing" the Year 2000 problem, these same systems are still prey to data received through Electronic Data Interchange ("EDI") or other external systems.

II.

PROBLEM COMPLEXITY

On the surface, the Year 2000 solution is quite simple. The basic remedy is to expand the date data field from six digits to eight digits of information. The extra two digits are used to represent the century value. However, the implementation of that solution is extremely complex.

Initially, an organization must examine virtually every program within that organization to determine if date processing impacts the program. Even within modest-sized corporations, systems can represent thousands of programs, consisting of millions of lines of source code and, on average, about six to ten percent of all lines of code process dates. Most likely, multiple programming languages (e.g., COBOL, Assembler, PL/I, etc.), multiple hardware platforms (e.g., IBM, DEC, HP) and multiple operating systems are in use. In addition, if the corporation has purchased or licensed software for internal use, that software too must be examined or verified to be free of any defects. The problem is further complicated by processing that can span several time zones or is distributed across LANS and WANS. And again, organizations must undertake all remedies within the very short period before the year 2000.

III.

APPROPRIATE SOLUTIONS

The most critical step in undertaking a Year 2000 project is to frame the problem as a management issue rather than a technical problem. Mislabeling the project will keep management from identifying the inherent risks associated with the problem. Furthermore, if considered only as a technical problem, the organization will likely apply inappropriate resources to the solution.

The organization must consider the Year 2000 problem as a managerial issue since the effects of the problem can impact the organization's ability to deliver goods and services. The solution may be technical in nature, but the Year 2000 problem is clearly one that management must own.

IV.

CRITICAL SUCCESS FACTORS

Organizations associate many success factors with the solution of a Year 2000 problem. Of those factors, two are critical. The first critical success factor is the undertaking of a business risk assessment associated with the Year 2000 problem. Business users should identify all areas (both internal and external to the organization) that date processing can impact. At a minimum, risk assessments should include financial, legal, regulatory, competitive and human resources. Determining whether a service or product has an associated Year 2000 risk, and then determining the degree of risk, will help in prioritizing corrective work. In addition, management must have this assessment in order to perform appropriate triage on the application portfolio. At this juncture, the organization may safely assume that it likely cannot fix the entire systems portfolio. Therefore, the organization should address only the most important (or risk sensitive) applications.

The second critical activity associated with a Year 2000 project is the management of the project by use of a formal methodology. All too often, IS organizations approach the Year 2000 problem simply as routine maintenance, only on a larger scale. In fact, the two are not related. The most obvious difference is the fixed deadline for completing the Year 2000 project. Beyond that, routine program maintenance rarely undertakes to overhaul an entire application portfolio simultaneously or within the context of rapidly escalating costs. Attempting to address the Year 2000 problem without a methodology will almost certainly result in squandered resources and inadequate results. In hindsight, the organization may be accused of negligence in its corrective efforts.

V.

CONCLUSION

Organizations should put aside any ongoing conjecture as to whether or not the Year 2000 computer problem is real or just another technology phase. Management must embrace and own the problem, and in doing so, look to the IS organization for solutions and approaches that can provide an efficient remedy. When solutions are not available, organizations should erect adequate fire walls (both technical and legal) to help insulate the organization from risks that will arrive with the new millennium.

Leland Freeman is Managing Director of Year 2000 Advisory Services at Management Support Technology, Framingham, MA. He is a frequent lecturer and author on Year 2000 computer problems who may be reached at lfreeman@mstnet.com.

Copyright Federation of Insurance & Corporate Counsel Spring 1998
Provided by ProQuest Information and Learning Company. All rights Reserved