|
|
|
|
|
|
|
"991231". Addition or subtraction may cause the value of the field to become negative or undefined. Use of such a date as a key in a random-access search system may produce bizarre results. In the most benign cases, mathematical operations will produce results which are very much expected, but certainly not desired. A classic scenario along these lines involves the mortgage payment due in 1900, which is therefore long "overdue", automatically triggering penalties or foreclosure. |
|
|
|
|
|
|
|
|
If this problem were detected in a single program or system, the fix would be relatively simple. You would write a simple file format conversion program to translate the affected files, reading in records in the old format and writing records in the new format. You would change field size declarations from two digits to four in affected application programs, test, document the changes, and go home early. |
|
|
|
|
|
|
|
|
Unfortunately, the actual problem is not so simple. |
|
|
|
|
|
|
|
|
1.8.1.2
The Magnitude of Y2K |
|
|
|
|
|
|
|
|
Y2K is a problem primarily because of the sheer size of the problem by a number of measures. Fixing a single bug is simple. The hard part of Y2K is not correction. The hard parts are identification, location, and testing. |
|
|
|
|
|
|
|
|
Identification is difficult because the bug is not specific to a language, and it can be manifested in many different ways. Location is extremely difficult because there are literally hundreds of millions of instances of the bug scattered through millions of programs. Testing is difficult because virtually all programs have to be debugged and tested, creating a problem of coordination to prevent cascading effects from one system to another. Since virtually every system must be tested, parallel system tests exceed the resources of most shops. |
|
|
|
|
|
|
|
|
There are several measures of the magnitude of Y2K. |
|
|
|
|
|
|
|
|
The proportion of programs affected. A 1996 survey of corporate customers by Viasoft, Inc., looked at software by industry type and found an average of 89.35 percent of all programs were affected by this one bug, with a range from 73.73 percent (manufacturing) to 93.75 percent (retail). |
|
|
|
|
|
|
|
|
Consider first what that means in terms of the book that you are holding in your hands. That study found that just one instance of one class of date/time code occurred in nine out of 10 programs. Y2K is hardly the only date/time bug in existence. Much less is it the only date/time code or the only potential date/time bug. |
|
|
|
|
|
|
|
|
Date/time code is ubiquitous. If you do not have solid date/time tools, you cannot write solid programs, period. |
|
|
|
|
|
|
|
|
The number of lines of code affected. Because date/time code occurs everywhere, it is necessary to look at just about every piece of code to determine whether it is affected or not. It is safe to say that the number of lines of code (LOC) potentially affected by Y2K alone is probably on the order of ten to the eleventh power, at a minimum. There are an estimated 180 billion lines of COBOL code on MVS alone. |
|
|
|
|
|