By Michael Roberts
By Amber Taufen
By Patricia Calhoun
By William Breathes
By Michael Roberts
By Melanie Asmar
By Michael Roberts
By Michael Roberts
Faced with cost estimates stretching into seven or eight figures to make their code "Year 2000 compliant," some companies are electing to do the work in-house or to ship their code to cut-rate programmers in India. But in many cases, no quick fix is possible; the array of date-sensitive functions on a mainframe can be so formidable and the programming so labyrinthine from years of poor maintenance and jerry-built patchwork that deciphering its mysteries has been likened to an archaeological dig.
"Some of these systems are twenty or thirty years old, and no one expected them to be around this long," says Taner Kodanaz, vice president of the Ciber2000 Group. "Probably a hundred programmers have touched these systems. It's almost like layers of earth--things have lived and died, and you see this history of what's gone on in the system. When we go into the code, we have to understand what was done and why, so the changes we make don't affect other functions."
Kodanaz says his team has encountered such a wide variance in the way programmers have handled certain tasks--everything from "spaghetti code," with paths snaking in dozens of different directions, to largely unstructured black holes--that they've taken to storing certain constructs in a database so they can refer to them in similar situations. Even in well-maintained systems, the coding can occasionally resemble a second-grader's first essay. "There's a lot of bad grammar in coding," Kodanaz sighs. "They have subjects where the verbs should be."
Up against an inflexible deadline, some companies have discovered it's already too late to upgrade their entire system--the expense is often prohibitive, and there isn't enough time to transfer data and debug it. So they're forced to renovate their existing code, through either field expansion (converting all years to four digits) or "windowing," which leaves the dates as two digits but adds code that tells the computer how to interpret them--for instance, that all years over 50 belong to the twentieth century and those under 50 belong to the 21st.
Windowing is a popular option among Ciber's customers because it's cheaper than field expansion, but it has drawbacks, too. Adding code can slow down operations, Kodanaz notes, particularly if you have a high-volume database that has to perform a "date check" before it proceeds with a given operation. And there's no guarantee that software vendors will adopt the same cutoff dates--such as 50--for windowing.
"One program could interpret a date as 1945, another could see it as 2045," Kodanaz says. "Not only do we need to fix the Y2K problem among components, we have to make sure that different programs interpret the dates the same way."
Of course, many computer users, such as insurance companies, may require longer timelines than windowing can provide; some are already engaged in 21st-century calculations and are experiencing what Kodanaz delicately terms "points of failure." Without naming names, Storrison mentions "a major film processor out of Rochester, New York, that almost dumped a lot of dollars' worth of film" because a computer inventory control system rejected product with an expiration date of 00, figuring it expired in 1900. Some credit-card readers are having a similar problem with shiny new Visa cards.
"This thing is real," Storrison says. "Banks, financial institutions, credit card companies--these people have to get it done, but some of them started only recently. Now they're throwing a lot more dollars and labor at it."
Many companies are approaching the problem on a "mission critical" basis, scraping up the cash to fix the systems that actually run the business; other, less significant Y2K problems may not be addressed until 2001 or later. But some surveys suggest that a great number of corporations--more than half of all American companies, and much more abroad--are still at an early stage of assessing their problems, despite the impending deadline and the need to test programs over a period of months after changes are made.
"No one wants to take the heat for this," says Hanifen Imhoff's Ollman. "It's hard for some computer guy to go upstairs and tell the head of the company he needs $20 million that they hadn't planned on spending, just to stay in business."
Welty suggests that smaller businesses may simply be unable to finance the fix, prompting a wave of bankruptcies and mergers in certain industries. "Can Chase Manhattan or Citibank spend $200 million on this? Of course they can," he says. "But what about some small bank in Nebraska or eastern Colorado? For some companies, the only option is to be bought out by someone."
If Welty sounds like an alarmist, it may be because government and major financial institutions have been downplaying the issue. Al Gore, the "technology vice president" who will probably be running for office in the year 2000, has been oddly silent about Y2K. The federal Office of Management and Budget has grudgingly revised its estimate of the amount the government will spend on Y2K problems from $2 billion to $3 billion, but outside studies suggest the fix could cost around $30 billion. Last week President Clinton announced the formation of a White House council to coordinate federal Y2K efforts--a move some critics regard as long overdue.