Rewriting computer code is not the only-nor the most difficult-part of the looming year-2000 problem, experts are saying.
The software programming challenge, what some call remediation, "is 10% of the effort," said Brian D. Robbins, Chase Manhattan Corp.'s senior vice president for enterprise information technology architecture. "The majority of effort will be spent on testing."
Already a buzzword, "year-2000" in automation terms refers to the programs that are likely to mishandle references to dates beyond Dec. 31, 1999. Interest rates could be miscalculated, accounting systems could go haywire, even heating and elevator controls could malfunction. And those are just the anticipated problems.
A study by Gartner Group of Stamford, Conn., said 94% of U.S. banks have begun to address the issue.
But many are starting too late to allow sufficient time for testing.
Experts said those in the early stages of a year-2000 project must understand that no "silver bullet" solution exists because fixes involve not only rewriting a bank's computer code but also analyzing external systems with which the bank has connections.
The good news for those just beginning is that those who went first created useful blueprints.
Chase, for example, divided its business units into 28 project offices. The units had to examine all internal systems as well as 680 third-party software packages and 2,900 outside interfaces.
By breaking up into groups, the bank was able to identify within six months what changes needed to be made. It now has completed most code alterations and has embarked on testing, which should be finished by the end of 1998.
An early lesson learned at Chase and other institutions is that sometimes it is both easier and more cost-effective to replace existing software with year-2000-compliant systems rather than to fix old programs.
Once decisions are made on which programs need changing, banks can use conversion software to seek out and execute the most obvious fixes. The rest require painstaking, manual alterations by skilled programmers.
Lou Marcoccio, Gartner Group's research director, said banks tend to use combinations of four methods of fixing code: modifying, expanding, encoding, and windowing.
Modification involves compartmentalizing problematic date references to shield them from interaction with other lines of code. Programmers then create a way to feed in correct date references.
Expanding refers to the lengthening of two-digit year references-the root of the entire problem-to four. Thus, 2001 will be represented in full rather than in the problematic abbreviation 01 that could be interpreted by a program as 1901. This can take up to five times longer to test than other methods, Mr. Marcoccio said.
Encoding involves shrinking four-digit year references so that they occupy the same space within a program as two-digit references.
Windowing is the simplest and fastest fix. It inserts logic that bounces references to years after 1999 to another section of code that determines what century the two-digit year belongs to.
Once the programming is fixed, testing can begin. Mr. Marcoccio recommended that banks exercise tight control over testing, handling as much as possible in-house.
He also stressed that banks must test all programs. A letter from a vendor certifying that its product is 2000-complaint does not free a bank from this responsibility.
BankBoston Corp. recently found during testing that a supposedly compliant software application was not so, said Steven McManus, communications manager for the bank's millennium project team.
BankBoston, which expects to spend $50 million on its year-2000 fixes, plans to start testing the way its systems interface with each other early next year.
"Some of this code can be old and fragile so when you do make a change you need to make sure it doesn't" affect anything else, said Mr. McManus.
For BankBoston, testing generally involves running routine transactions as if they are occurring on key dates: Dec. 31, 1999; Jan. 1, 2000; Jan. 3, 2000; Feb. 29, 2000; March 1, 2000; and March 31, 2000.
Even after testing is completed, banks must establish procedures for dealing with glitches that could arise once programs begin running real- world applications.
In its projections of the industry's year-2000 costs, Tower Group said it sees more than $1 billion being required in 2000 for "cleanup" work.
"For almost no bank is it possible to set up a complete parallel environment for testing all systems to ensure all changes do work," said George Kivel, group director of wholesale banking at Tower Group in Newton, Mass.
"You have to get the best people who understand the project and lines of business," he said. "Many people don't have the experience to do this."
