Newsweek: Why Y2K Won't Die

greenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread

http://newsweek.com/nw-srv/printed/us/sr/a47027-2000jan2.htm

[Fair use/educational purposes]

Glitch Watch: The Millennium Bug didn't cause the digital apocalypse many feared. But there still may be big headaches to come.

By Jared Sandberg Newsweek, January 10, 2000

So it wasn't the end of the world. The specter of a worldwide digital meltdown began to evaporate as the new millennium dawned around the globe Friday night, leaving billions of people united in a collective shrug. So far, even those who weren't fearing the worst seemed disappointed that the bug had no bite. But to those still hunkered down in their bunkers, glumly contemplating a lifetime stockpile of lentils, many computer experts hold out at least a tiny glimmer of despair: the real effects of the Y2K Bug may not be felt for days, weeksor even until the year 2001. So don't break open the bottled water just yet. To be sure, the most spectacular of the predicted disastersranging from elevators that refuse to budge from the lobby, to malfunctioning air-traffic-control systems, all the way to the unintended launch of a nuclear missilefailed to materialize. Essential services were maintained throughout the developedand even the developingworld, as far as anyone could tell in the first hours of the new year. But other, subtler flaws may yet lurk in the interstices of banks, insurance companies, utilities, transportation services and government agencies. Some glitches were expected to start showing up this week, as business as usual resumed around the world; others may become apparent only as thecalendar progresses through a year's worth of billing cycles, interest periods and payment deadlines. Some of the relief that people felt on hearing a dial tone Saturday morning will undoubtedly dissipate if they get a bill for a hundred years' worth of phone service. "What you might get over a period of days or weeks is some degradation of quality," says Bruce McConnell, director of the International Y2K Cooperation Center. "It's going to gum up the works with annoying inconveniences."

A minority of experts thought that the dangers went beyond inconvenience. Ed Yardeni, chief economist at Deutsche Morgan Grenfell and a leading Y2K bear, warned about the possibility of a recession if computer glitches in foreign countries held up imports of raw materials or other goods. "Nobody really knows where the weak links are," Yardeni said last week. "But we're all going to find out together." At a mostly upbeat New Year's Day press briefing, John A. Koskinen, Washington's chief Y2k troubleshooter, said that among the five leading oil exporters to the United States, Canada and Mexico seemed secure. That left Nigeria, Venezuela and Saudi Arabia. "Are we satisfied that all of those other countries are now out of the woods?" Koskinen said. "The answer is no."

In general, small businesses, with fewer resources, are more at risk from computer screwups than giant corporations. Most people, of course, will survive a meltdown of their dry cleaners' data-processing software; unfortunately, though, most health-care providers are small businesses, as these things are reckoned. Chronically strapped for cash, the industry was among the last to tackle Y2K problems. Even before the end of last year, 10 percent of 2,000 health-care companies surveyed said they had experienced Y2K-related failures. Without centralized coordination like that in banking, there's little sense of how well the health-care industry has prepared. Some experts also fret that it remains vulnerable to the supply-chain problem. "There are a lot of steps in getting something from the rain forest into somebody's bloodstream," says Joel Ackerman, executive director of Rx2000, an information clearinghouse for the health-care industry. Any bumps along the way, he says, and we may not know until shortages show up in the second half of the year.

And even as the world awaits problems caused by Y2K bugs that went unfixed, it will confront a whole new category of problems resulting from programs that were fixed. "For every thousand changes you make to a computer system, you get eight new problems," says Peter de Jager, a prominent Canadian consultant who was one of the first to sound the Y2K alarm. "If every company and government agency has just a few problems, that still means millions of problems. The notion that all the work ends Jan. 1 is bogus." Newly written computer code is only as good as the procedures for testing it; in the wrong place, one untested line of code can have a ripple effect, not just in the program that contains it, but in all the programs that interact with it.

De Jager's comments, as it happens, were meant to reassure programmers who shared in the largesse of the $500 billion Y2K-repair industry and may now be worrying about where their next bag of Doritos is to come from. Luckily for them, the vast worldwide effort to keep computers on track past the end of 1999 meant that a lot of other important programming work got shelved over the last year or two. Innovations such as "decimalization" of the stock exchangesquoting prices in dollars and cents, rather than fractionswill keep programmers busy, and computer users on the alert for bugs, for years to come.

In fact, the next big test for computers will come in just two months, on Feb. 29, 2000a date that many programs, alas, may not know exists. This so-called leap-year bug results from a peculiarity of the Gregorian calendar, which inserts an extra day at the end of February every four years, omits it on years that end a century, but puts it back in when the year is divisible by 400. Programmers who knew the secondof these rules but not the third would have instructed their computers, erroneously, that 2000 is not a leap year. This could result in all kinds of problems if the computer happens to be, say, keeping track of an oil tanker expected to arrive in port on the day after Feb. 28. "We worked with 300 companies, and every single company had some leap-year problems," says Nigel Martin-Jones, executive vice president of the high-tech consulting firm Data Dimensions.

No one is making the same kinds of apocalyptic predictions about Feb. 29 that were bandied about in the weeks leading up to Jan. 1. But anyone still holed up with his diesel generator this week might just want to keep his tank full for another couple of months.

With David A. Kaplan

) 2000 Newsweek, Inc.

-- Steve (hartsman@ticon.net), January 07, 2000

Answers

Two hundred health care providers experienced problems before the rollover!?

Hmmmm, I remember Hershey, Whirlpool, Royal Dalton and a handful of others.

Now, I consider my self fairly well-read and I do not remember seeing any mention of this figure.

Any one ever hear this statistic? Wonder what the author's source of info is.

-- Cant Say (Chicken@NoWay.com), January 07, 2000.


Feb 29 is going to be a non-issue. Here's why:

The bozo programmers who don't know the leap year rules will be saved by fluke since 2000 is divisible by 4 and is a leap year.

The smart programmers who know the leap year rules will say, "So what". I don't need to program them until 2100, because until then the divide by 4 rule is good enough and I know that all my software won't be in use by 2100 (hmm, seems to me I've heard that before, ah yes it was said in reference to software that won't be in use in 2000 so it would be ok to use 2 digit year programming).

The only time there will be problems on Feb 29 if there were some real smart ass programmers who know the rules and programmed them incorrectly or there were real bozo programmers who know about leap years but couldn't even program the divide by 4 rule properly (or even better forgot leap years exist - in which case their apps already blew up in 1996).

So the errors that occur on Feb 29 will be the result of sloppy programming, not due to igorance of the fact that 2000 is a leap year. These my guess will be few and far between unlike y2k where there was specific decisions made not to program 4 digit years and therefore was a design issue rather than just sloppy programming.

-- Interested Spectator (is@the_ring.side), January 07, 2000.


Moderation questions? read the FAQ