Y2K Issues Still Remain

WHILE FEW observers are claiming outright victory in the battle against year-2000 computer problems, the relatively quiet passing of Jan. 1 has led to somewhat rosier expectations for the rest of the year.

However, observers caution that a fairly steady stream of year-2000 glitches will occur, especially in financial systems, and that litigation will result in some instances.

"We're not out of the woods [yet]," said Stephanie Moore, an analyst at Giga Information Group, a market research company, in Cambridge, Mass. "It could be at least 12 months before we see the complete impact."

Forecasts have predicted continuous, but fairly sporadic, occurrences of year-2000 bugs.

"I think the number will be relatively low, and they'll be isolated and random," said Harris Miller, president of the Information Technology Associates of America (ITAA), in Arlington, Va. "A lot of them, unfortunately, will be in financial software and financial transactions. So when people are closing the books on a given period, there may be strange results."

In light of the vast sums paid for year-2000 preparations, the contentious issue of who ultimately foots the bill is coming to the fore.

"At this point, many companies are exploring ways to recoup costs, not for failures but for preparations," Giga's Moore said.

In a number of high-profile cases, companies are suing their insurance companies to cover year-2000 costs (see "Y2K legal wrangling escalates," www.infoworld.com/printlinks).

Although the relatively calm transition bodes well for a placid overall legal situation -- compared to early expectations of a litigation free-for-all -- suits are expected to continue to mount, both against software vendors and as a means to recover preparation costs from insurance companies, according to Lawrence Kulig, a partner at Goldstein & Manello P.C., in Boston.

So-called downstream cases, those arising between supply-chain partners or by customers against vendors, are expected to be rarer, according to Richard Gilbert, another partner at Goldstein & Manello.

"In the future, you will also see some cases where people paid a lot of money and, given the nonappearance of problems, feel that they ... got scammed," Gilbert said.

While few organizations are expected to volunteer details of year-2000 bugs, evidence of the date-handling problem could emerge as companies issue earnings warnings in the coming quarters, Giga's Moore said.

"[But] the sense I'm getting is that companies are eager to cover up Y2K glitches," Moore added.

However, companies, particularly public ones, face some legal pressure to be forthcoming.

"Under federal law, publicly traded companies are required to report Y2K failures if they have a material impact on their operations," Gilbert said.

"For private companies, it's harder to address."

The ITAA's Miller maintained that companies were not under any obligation to report every year-2000 glitch, any more than they would be to report routine systems problems that can be addressed without hampering business. He said that on the post-year-2000 IT spending front, a moderate increase is likely.

"I do expect an increase, since manpower and financial resources were diverted to Y2K," Miller said. "But the idea that the floodgates would be opened is an exaggeration. In fact, some IT budgets will be cut back."

NOW FOR THE LEAP-YEAR CHALLENGE

Year-2000 programming staffs long tired of date-change problems now face a tricky, but lesser, issue -- leap year. Because of a series of confusing calendar caveats inscribed centuries ago, federal officials believe that some programmers miscalculated and assumed that the year 2000 is not a leap year when, in fact, it is.

If programmers stuck to the general leap-year rule -- that they occur in years divisible by four -- they would arrive at the correct conclusion that 2000 is a leap year. But if they were to get mired in the exceptions for leap years, systems would be programmed (incorrectly) to leave out Feb. 29.

Specifically, there is an exception to the divisible-by-four rule: Double-zero, or centuries, are not leap years. If a programmer has latched on to that exception, there could be trouble, because there is another exception:

Centuries divisible by 400 -- including 2000 -- are leap years.

"Well, the leap-year problem, I thought when I started, had to be inconsequential because to do it wrong you had to know just enough information to get into trouble," said federal Y2K pointman John Koskinen at a New Year's Day briefing. "I didn't figure there could be very many people that got it halfway right and halfway wrong," he added.

To be safe, federal and private sector officials have been including leap-year tests in the battery of routines to prove a system is year-2000 compliant.

Carnegie Mellon University's Software Engineering Institute's CERT Coordination Center is predicting that any leap-year glitches will be minor.

But CERT officials say there could be problems with financial and business systems such as payroll and billing, if there are any instances in which 2000 was not treated as a leap year.

CERT officials said that so far Apple, Microsoft, Linux, and Sun's Solaris operating systems have been reported as having no problems with the Feb. 29 date. Other vendors, including Compaq and Fujitsu, reported to CERT that their products are leap-year compliant.

Join the newsletter!

Or
Error: Please check your email address.

More about Carnegie Mellon University AustraliaCERT AustraliaCompaqFujitsuGiga Information GroupITAAMellonMicrosoft

Show Comments