|
This report from Data Dimensions reveals why we do not have until 2000 to get prepared. Many mainframe computers have a 99 problem, too.
Conclusion: the deadline is 12/31/98.
* * * * * *
The digit "9", used in the data singly or as a series of nines, since the beginning of data processing, has held special meanings. The meanings could be end of record, end of file, error return, cancellation, start, special discounts, missing date, or keep forever, to name a few. In some cases, the conditional nine is included in the programming language itself to have special meaning. In fact, "9" is the most frequently used element to mean transfer of logic.
During one of the early project reviews (1991), a client told a story about a new financial system that had been tested post 2000 in processing, but when 1999 was used, the system only returned error code messages! (Took 90 days to fix and retest.) The problem and its immediacy are discussed in greater detail in this article - we believe this problem is very real and urgent! Please pass this article around to your friends and colleagues. . . .
Event Horizons can vary between Enterprises. For example, the U.S. Government's fiscal year 2000 begins on 10/1/99. This moves the 12/31/99 Event Horizon to 10/1/99. There are many factors specific to each program that can change an Event Horizon.
One of our clients, a large manufacturing company, reported that one of its financial programs needed to access the bank holidays (stored in a database) for the current year and the following year. This implies that this company actually had an Event Horizon of 1/1/99 for that program. (The date, 1/1/99, is the first bank holiday of the year.)
Background on the "99" Problem
Many programmers did not think that their software would still be in use in 1999. Therefore, programmers often coded date fields with "99". Using "99" as program logic was standard practice at the time the products were created. The value "99" frequently was used to mean the following: end of record, end of file, error return, cancellation, start, keep forever, or other special commands. . . .
One of our clients, a large insurance company, uses IBM AS/400 computers. Like many AS/400 users, our client initially had System 38 and then upgraded to the AS/400 within the past five years, but has kept the original System 38 programs. In most cases, these computers use the languages, RPG and RPG III. Unfortunately, the teaching of RPG III encouraged the use of "99" as a program logic switch. As a company programming practice, programmers designated the "end of file" condition with a transaction date of "99". They have now realized that almost all of their programs will not work when they begin entering "real" transactions with an expiration date of 1999. This is a very serious situation for many AS/400 installations because this practice was very common with the System 38s. . . .
A program that contains a date field may require the user to insert "99", if the record is to be deleted or archived. When the year is 1999, the program logic to delete or archive the file will override the date field. Records in 1999 may be deleted because of the computer's program logic. . . .
Most information about the Y2K problem lists 12/31/99 as the typical Event Horizon. Although 12/31/99 has been widely publicized as the critical date for most systems' Event Horizon, 1/1/99 or 9/9/99 may actually be your organization's Event Horizon. Regardless of what other systems do, what will your computer do when it rolls over to the next "logical" date?
Experts in the field have suggested that you should tackle the problem by 12/31/98, so that your applications can be sufficiently tested. If the Event Horizon is 12/31/99, then implementations should be made by 12/31/98, so that the applications can have a full year's business cycle of testing before the Event Horizon arrives. However, if your system is affected by the "99" problem, then your Event Horizon should be 12/31/98.
This systemic failure due to "the nines" is potentially very damaging. It is no major exaggeration to say that every date processing program is potentially vulnerable to this error. And, it is almost too late to fix the problem before failure occurs. Unless immediate action is taken to address and solve the 1999 date problem, computer failure is inevitable.
|