Rick Flagler, information systems manager at Miniature Precision Bearings, says he originally "freaked out" at his 2000 problem.
He also freaked out over a consulting firm's $US2 million estimate to fix the problem - for just one of the company's divisions. Instead, Flagler's group developed its own methodology and conversion software. He now estimates he'll do the whole job - on millions of lines of IBM AS/400 Cobol, RPG and C code - for less than $200,000.
Flagler is one of a growing number of IS managers who are finding that January 1, 2000 won't end the world as they know it. Vendor and press hyperbole notwithstanding, there are ways to approach the problem - and some lucky circumstances - that allow them to sleep nights.
Indeed, some companies and federal agencies are spending millions on pound-foolish projects when penny-wise patches might do, says Thomas Giammo, the former head of IS at the US Patent and Trademark Office. In many cases, 2000 projects are driven more by fear than by rigorous analysis of need, he says.
"The alarmists have seized the field, and the burden of proof seems to be on those who say it's not that critical," Giammo says.
"I can see where some companies are in trouble, but vendors are really playing on the emotions of companies that are not in trouble," says Chuck Meehan, director of management information services at Insituform. "Some companies are spending huge amounts to change out their total software, which is asinine."
Heat from the top
According to Meehan, IS managers are being pressured by CEOs who have received scare letters from vendors, auditors and lawyers. "These IS directors have just been beaten over the head," he says, "but we've been our own worst enemies because we haven't taken the lead on this."
Although it clearly would be foolish to dismiss all 2000 angst as unfounded, there are organ- isations that have little to fear from the date change. A company comfortable with the problem probably falls into one or more of the following categories:
It started early, worked diligently and is now finished or nearly finished with conversion workIt has replaced its date-challenged legacy systems with client/server applications that proudly display four-digit year fieldsIts software is provided by others, and its vendors or outsourcers have certified that they comply with 2000 requirementsIt has a world-class IS shop, with low turnover, plenty of legacy programmers, good control of source code, excellent documentation and a healthy budgetIts systems aren't date-intensive and don't affect daily cash flowThere is some evidence that the wave of concern over 2000 may have crested.
A recent report from Forrester Research said the problem has become "the most hyped issue in the history of IT". The IS research firm says companies it recently surveyed say they're spending US95 cents per line of code for 2000 work, more than a third less than the oft-cited industry estimate of $US1.50.
"Companies that are into it are starting to say, 'Now that we are actually fixing code, this isn't quite as daunting as we thought'," says Russ Maney, a director at Forrester.
Flagler says the following factors make him relatively comfortable with the 2000 challenge: low IS turnover, good documentation, an early start on the problem, management commitment and internal staff dedicated to the project, a sound methodology and a decision not to convert noncritical reports and screens.
Flagler says he expects to be done with 2000 work by year's end, but he concedes that he's less confident that his vendors and business partners will be ready on time. "The area I'm still uncomfortable about is outside the data centre," he says.
Wayne Lambert, chief information officer at Colorado Compensation Insurance, is another member of the what-me-worry club.
"It's not a big issue for us because we rewrote our systems in 1992 to handle the century change," he says. They were overhauled again this year for client/server, and they remain 2000-ready, he adds.
But like Flagler, Lambert admits to having less confidence in his software vendors and business partners. "We are asking for letters certifying they are Y2K-compliant or giving a date when they will be so we can test their applications," he says.
Alan Dechert, a software test engineer, says some organisations are going overboard by making sweeping changes to their systems, especially by changing all two-digit year fields to four-digit fields.
According to Dechert, at least 50 per cent of the 2000 effort could be avoided by using "windowing" logic, in which programs assume that a two-digit date within a predefined range belongs to a particular century.
Members of the 2000 minimalist school say it's cheaper and less risky to leave many programs unchanged and just fix them when and if they break. "If I fell asleep on the job for the next two years, the consequences would be minimal," says Dechert, who is writing a 2000 test plan for a public works agency. The agency's key systems are billing applications, and invoices would be delayed just a day or two if date bugs had to fixed, he says.
But Ray Strecker, a vice president and 2000 specialist at American Management Systems (AMS), says the minimalist philosophy may have troubling legal implications. "If you're a firm with a substantial balance sheet, you have no choice but to take the problem very seriously because that's the only action you can defend in court," he says.
But, Strecker adds, that doesn't mean there are no shortcuts. For example, you might leave unchanged an application that tracks 90-day work orders. It won't sort properly for a three-month period bracketing January 1, 2000, but it will correct itself. "You just tell people, 'Look, manage through it; we are not going to change it'," he says.
It's impossible to completely validate vendors' claims for 2000 compliance, warns Leon Kappelman, co-chairman of the Society for Information Management's International Year 2000 Working Group. Testing is essential, he says, and it may also be necessary to set up filters to block noncompliant transactions from critical internal systems.
But no matter what you do, you won't know whether systems are compliant until the date change occurs, experts say. "You will never find all the date problems," Maney says. "Of those you do find, you'll never fix them all right. And of the ones you fix, you'll never test them all right."
La la land
Many of the companies saying 2000 is no big deal are "in la-la land", especially those that haven't started their work, Kappelman says. For example, he says, a large manufacturing firm recently said it might use brand-new applications from SAP America to solve its legacy 2000 problems. "But they are a four-year SAP project," Kappelman says. "They should be doing triage - what do they have to fix now?"
As for those companies that might appear to be replacing legacy systems unnecessarily, there's a method to their madness, according to Kappelman. Under standard accounting principles, the capital cost of new systems can be amortised over several years, whereas "repairs" to existing systems must be expensed immediately. Also, it's a way for IS managers to avoid the suggestion that they're spending huge sums to remedy past coding blunders.
Patricia Boyce, a project leader at Scottsdale Insurance, scoffs at the notion that the problem can be easily solved in the course of routine maintenance. The company is about 75 per cent through its 2000 project, which despite the use of an automated tool to convert date fields, has so far taken 17,000 hours from 30 people in IS, plus six outside consultants. The company employs 100 IS people.
Boyce agrees that windowing can be a valu- able shortcut if used judiciously. The company expanded the year fields in its data files but left them unchanged on many of its 1000 screens, and that may have saved 10,000 hours of effort, she estimates.
The sharply divergent views of the year 2000 problem at Scottsdale Insurance and the public works agency possibly can be explained by how dependent they are on their applications. The insurance company's core systems are online applications that must be available nearly 24 hours a day for processing policy and claims information.
But the public works agency billing systems are batch systems that could be down for a day or so for repair without catastrophic consequences.
All the debate about windowing, application triage, automated tools and so on misses a key point about 2000, says Bruce Webster, chairman of the Year 2000 Group in the US. "I don't think it's a technically overwhelming problem, but I think it's going to whack us on the head just because I know how poorly corporations deal with software development in general."
Indeed, it seems likely that most organisations will get at least a little whack on the head from the 2000 problem. But quite a few companies have found ways to limit their vulnerability.
Realistically assessing that vulnerability is not easy.
The bug report:
Client/Server bugs and fixes
Windows NT 4.0. If you are doing an unattended installation of the German version of Windows NT 4.0 Workstation for Novell NetWare 4.10, the install screen stalls for approximately 10 to 15 minutes when the progress bar is about 80 per cent. The installation will eventually finish correctly. A fix is available in the file OEMNPRNW.INF, which you can get from Novell Technical Services. Novell officials also said you can get the file NWSETUP.DL_ from the English version of the NT client and substitute it.
Lotus Notes 4.6. If you use server-wide Custom Response Pages on the new Lotus Notes 4.6 server, you may run into server reliability problems on both the Windows NT for Intel and Digital's Alpha platforms, according to Lotus. They give no fix, so evidently you should stay away from using those types of pages.