For some, the end of the decade conjures thoughts of a promising new millennium. But to many computer system operators, the vision may be of an apocalypse.
When the clock strikes midnight and 1999 turns to 2000, thousands of computers will suddenly seize up or seriously malfunction.
The problem stems from the fact that computer programming standards were set without regard to the change. Because years are entered in two-digit shorthand, "00" would be read as 1900, not 2000.
The answer lies in expanding the year space to four digits - a complex and expensive programming challenge.
The predictions of doom have spawned heated debates among systems experts and consultants. The issue has important implications for banks, because they deal in financial accounts and instruments that are heavily dependent on date references.
Many bank executives are having a hard time taking the "2000 crisis" seriously, but consultants and technology companies are doing their best to change that. A cottage industry has grown up around solving the problem, and its rhetoric is hard to ignore.
Some call the preparations the largest cross-industry computer project ever. Reprogramming cost estimates range between 50 cents and $1.50 for every line of code on companies' systems.
Estimates of the aggregate modification cost worldwide run into the hundreds of billions of dollars.
Bankers who have begun facing the challenge said some of the talk is hyperbole - a scare tactic designed to get businesses to buy the necessary support services. But the bankers do not deny that the situation requires attention.
And the consequences could be dire for those that do not begin making changes soon.
"If this is not addressed, it will bring business to a grinding halt," said Brian Robbins, vice president of information technology architecture at Chemical Banking Corp. (He will hold the same position with Chase Manhattan Corp. when the two banks complete their merger.)
On most bank systems, today's date in computer code would be 960307. The same date four years from now would be 000307.
Older systems would logically assume that any loan with a maturity date beyond 2000 is seriously past due.
The remedy - expanding the two-digit year fields to four digits - is time-consuming and can be expensive, bankers said, although the costs would vary widely from bank to bank.
In general, those with older hardware and software have more work to do, because only the newest components of bank computer systems tend to be ready for the conversion.
Experts note that the problem requires modification not only of computer applications, but also of computer files. Thus, a bank cannot just modify its demand deposit software, it must also make sure that files, such as those tracking bounced checks, acknowledge the calendar change.
James McCann, year-2000 business manager at EDS Corp. in Dallas, said data fields left unmodified may not bring every single bank to its knees.
But ignoring the date problem would most certainly lead to uncertainty over calculations, "and that's the insidious thing about the issue," Mr. McCann said.
He and others noted that spending the money to fix computer code is not an optional expenditure: Banks need to approach it as a cost of doing business.
And the time to act has arrived.
"A lot of problems have already begun to surface," said Steven M. Kagan, a director at Integrated Systems Solutions Corp., the outsourcing unit for International Business Machines Corp. "The date-change problem is more prevalent at financial services companies."
The first step is to do an inventory of computer code that would be affected by the date change. Most of the major vendors of bank computer services either make or have access to software that can ferret out date references.
Once the date fields are located, they need to be given a priority - a line of code in a computer program that creates an internal report may get a lower priority than a program that calculates interest on a security.
Using the priority list, corrections to data fields can be made. Again, a myriad of software tools are emerging to help with this process.
Working in the bank industry's favor is the fact that merger-related computer consolidations have taught many institutions how to take inventory of their systems and prioritize projects.
Chase and Chemical, for example, are using an inventory of systems applications compiled for their merger consolidation to guide their year- 2000 project. Many applications are slated to be modified after the merger, and calendar-related changes are being incorporated into those projects, Mr. Robbins said.
In addition, bankers and consultants note that not every problem with the date change needs to be addressed by the end of 1999. Some may be able to wait until 2002.
However, before banks can decide which projects to postpone, they must assess the scope of the problem. And there are some indications that bankers are beginning to acknowledge the gravity of the situation.
Several of the largest financial institutions are in early stages of working on the problem. Few have any idea how much their remedies will cost.
Many community banks may lack direct control over solutions, because they depend on outside service bureaus for data processing.
Consultants say there is no easy solution. The projects will tend to be time-consuming and expensive.
"The scope and due date of the year-2000 issue is set - it's not negotiable," said Mr. McCann.
Mr. Robbins at Chemical said the cost to fix the problem is immaterial, because "you've got to do it."
However, he added, "This is nothing so complex that we can't do it."
