99 Bug to Precede Y2K Bug

from The Washington Times

METRO
Bug may sting computers before 2000
Some technology experts fear 1/1/99 and 9/9/99 glitches
By Stephen Dinan, THE WASHINGTON TIMES

Those who think they have until the beginning of the next century to fix the year-2000 computer problem are in for a shock.

A year from tomorrow, tens of thousands of computers could skip or delete critical data or fail to make calculations properly — all because programmers long ago used the series 9999 in computer codes to mean anything but Sept. 9, 1999.

Experts say Sept. 9, 1999, will be a real test of how many computer systems are still vulnerable to the so-called “millennium bug.” It could mean bad reports and wrong answers on everything from air-traffic control and bank balances to tax collections and building permits.

Technology experts are even more concerned about Jan. 1, 1999, little more than 100 days away. That’s when many corporate and government computer programs begin making one-year calculations and projections that for the first time will reach the year 2000.

“Most companies started late, are moving too slow and are too optimistic” to be ready for Jan. 1, 1999, says Jim Woodward, senior vice president at Cap Gemini America, an information-technology consulting firm. “This is too big, too pervasive to get it perfect, probably.”

Computers that do everything from issuing paychecks to controlling stoplights to targeting missiles need to be able to add and subtract dates and years.

But many old programs were written assuming the year always would begin with “19.” Put simply, the year-2000 computer problem means that if an unknown number of programs and microchips around the world aren’t fixed or replaced, computers that read “00” as the year 1900, not 2000, will
fail or malfunction on Jan. 1, 2000.

The dates Jan. 1, 1999, and Sept. 9, 1999, are just two of the pre-2000 dates that may trip up computers that aren’t rendered “year-2000 compliant.” Dates signifying the end of a quarter, a month or a fiscal year also pose potential trouble for specific industries, companies and government agencies.

As with the larger year-2000 problem, the question nobody can answer is exactly how big a headache these dates will prove to be for millions of computers that we depend on for everyday life and business.

Unlike the year-2000 bug, the Sept. 9 snag is not about computers assuming it’s 1900 when reading a two-digit date. It has the same root, though: Programmers failing to anticipate the future. They designed some programs so that if someone entered a series of nines in the place where a date goes, it meant no date was available. The program often made special exceptions for that record. And that’s exactly how an uncorrected system would interpret data actually entered on Sept. 9, 1999.

In other instances, programmers used a series of nines to mark the end of a file. An uncorrected system thus might skip over other valid data after reading a series of nines meant to represent the date — 9/9/99 — not the end of a file. The program can’t produce the correct response.

Some programmers used nines as an expiration date for data, meaning that a year from now, uncorrected systems could delete material that contains “9999” — all because programmers didn’t think their programs would still exist next year.

The good news is that if your local governments, banks and companies already are combing computer programs to make them ready for Jan. 1, 2000, they’re almost certainly looking for other problem dates, industry experts say. But if they haven’t begun serious work, the year-2000 problem first may be a year-1999 problem.

Top of Page | 5 Issues for 1999-2001 | Home Page

Donald Evans, director of information systems and telecommunications for Montgomery County, says counties and cities that far behind had better focus on contingency plans, and fix what small things they can.  He and other technology experts say the “secondary” benchmark dates are nowhere near as serious as Jan. 1, 2000, but could give us a preview of what to expect.

Montgomery County computer programmers have checked for the “nines” problem along with other critical dates, though Mr. Evans says they don’t keep track of how often they’ve found and fixed it.

Fairfax County’s computer workers say they are replacing entire computer systems in the public schools to make sure such dates don’t become programming glitches, but have not seen it as a major concern in fixing other government systems.

The District also is on top of the pre-2000 date traps, says D.C. chief technology officer Suzanne Peck, although she wasn’t familiar with the phenomenon until The Washington Times asked about it. After a phone call to IBM, which the city pays $2 million a month to exterminate its millennium bugs, she reported the computer giant has got it covered. Both Cap Gemini’s Mr. Woodward and Barry Ingram, vice president and chief technology officer for EDS, say they expect the “nines” fallout to be relatively minor.

Mike Humphrey at Public Technologies Inc., which helps associations of cities and counties with technology issues, is more concerned that the situation not turn into a case of “the boy who cried wolf”:

If no significant breakdowns occur on Jan. 1 or Sept. 9 next year, some computer users might dismiss the year-2000 issue as hype and hysteria and halt expensive repairs months before the big problems predicted by many experts on Jan. 1, 2000.

Still, potential snags on the earlier dates have to be found and fixed. In Maryland, Frederick County had to fix computer systems that monitor jail sentences before last July 1. The maximum sentence for those doing time in the county jail is 18 months, and the old program made the computer read a release date of Jan. 1, 2000, as Jan. 1, 1900. Come July, the computer would have started reporting inmates had done their time.

Capers Jones, a scientist at Software Productivity Research Inc. and one of the foremost experts on dangerous dates for computers, uses the example of a pharmaceutical company that made a drug with a shelf life of four years. In 1996, the company produced batches of the drug and then, later in the production cycle, destroyed them because the computer “thought” 1900 was the expiration date.

Staff writer Jeremy Redmon contributed to this article.

Top of Page | 5 Issues for 1999-2001 | Home Page

Copyright 1998 News World Communications, Inc. Reprinted with permission. All rights reserved.