NYTimes: '99 Problem Trips Up Few Computers

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

http://www.nytimes.com/library/tech/99/01/biztech/articles/11bug.html (free registration required for the NYTimes site)

"The world apparently sailed through the first days of 1999 with only scattered mistakes by computers confused by the approaching Year 2000 -- an outcome that added to growing optimism about the chances of avoiding widespread disruptions 51 weeks from now.

Transitions to new years are always a bug-ridden time for information managers, because some devices and programs do not automatically adjust calendars. But computer users had feared that the advent of this year might be rougher than usual because many computer programs look a full 52 weeks ahead and so would be encountering dates in 2000 for the first time.

Reports filtered in about mixups with taxi meters, with accounting software that spewed out faulty bills or -- alternatively, failed to issue valid ones -- and similar glitches. But the disruptions seemed to be isolated, quickly handled and in some cases not really linked to the 2000 date at all. Year 2000 experts were especially impressed that the financial sector had fared so well, despite having also committed huge computing resources to the introduction of the euro, the new European currency that began trading last week.

"It points to the likelihood of a few hellish days rather than big failures next year," said Ian Hayes, president of Clarity Consulting, who advises large multinational clients from his base in South Hamilton, Mass.

The Year 2000 problem stems from the longtime use of just two digits to refer to the year, and the inability of some computers to recognize 00 as 2000. Some computers mistake 00 for 1900 while others, programmed to expect steadily higher numbers in their two-digit year data, cannot read 00 at all and shut down or revert to some earlier date.

Another uncertainty last week was whether some computers using two-digit dates might be tripped up by programs that had used the digits 99 to mean "end of file," "shut down" or some other message having nothing to do with dates. That practice was used as a shortcut by an unknown number of programmers.

It is unclear whether the 99 problem is a serious threat. For one thing, the use of two or more 9s as an end-of-file signifier within date programs is relatively rare. And even where it does exist, it is typically easy to locate. In any case, although some had warned that this last week was also a danger zone, Sept. 9, 1999, is seen as the most likely minefield of 9s.

In the end, the most widely reported glitches last week turned out to be 99 problems, not failures to handle 2000. Taxis in Singapore, for example, were unable to run their meters for several hours on Jan. 1. And some in Stockholm -- to the delight of Swedes out celebrating the New Year -- were unable to switch to higher fares authorized for 1999.

DaimlerChrysler Corp. discovered on Jan. 1 that a program in its regional data centers that helps run auto production had a 99 problem that could be fixed by the same patch the company was planning to install later this quarter to deal with a Year 2000 defect. So Chrysler rushed the patching job through, and no disruptions were suffered, according to Roger Buck, head of the company's Year 2000 project.

Goldman, Sachs & Co. said it encountered four minor glitches, including a commodities accounting program that would not allow it to schedule a metals payment in the Year 2000. It turned out that all four defects had been identified by Goldman's code scanners and would have been scheduled to be eliminated anyway by program fixes set for this spring. "I feel good about that, but it doesn't mean we are going to cut back on our contingency planning or other Year 2000 work," said Leslie Tortora, the firm's chief technology officer.

As expected, government computers in Washington and in several states were unable to sign people up for unemployment benefits using standard forms, which set a date one year ahead as the end of the benefits. But, as previously planned, those agencies continued to sign people up for the benefits last week by plugging in Dec. 31, 1999, as the ending dates.

"It will create a nightmare of paperwork to rework these if it goes on for long, but most systems should be ready for Year 2000 dates by the end of this quarter," said Howard Waddell, a Labor Department spokesman.

John Koskinen, chairman of President Clinton's Council on Year 2000 Conversion, said the unemployment benefit scramble underscored the need to plan for breakdowns well in advance. He said he was worried that last week's calm might encourage local governments and small businesses to settle on "wait until it breaks" policies.

Environmental Systems Products in Bohemia, N.Y., was one company that paid a price for not paying attention in time. One of three companies that supplies automobile emission-testing equipment for use in New York state, Environmental Systems was surprised to discover that equipment it had been phasing out could not produce a 00 windshield sticker for drivers whose vehicles had passed inspection. Stickers in New York use two digits for the month and two digits for the year to indicate the expiration date for an emissions validation.

The 00 sticker should have started appearing Dec. 22 because New York motorists get a grace period of eight days for their one-year validations. But the older Environmental Systems equipment printed out stickers saying 91 instead, and many inspection stations simply put them on car windows. Parking agents promptly began ticketing the apparently out-of-date cars.

Environmental Systems quickly reported the problem to the state and procedures were set up to quash the tickets, but the crash effort to complete the transition to newer equipment that issues 00 stickers was not completed until last Wednesday.

"It cost a lot of money," said James Richardson, the company's director of operations.

Hayes, the consultant, cautions "there are a hundred problems for every one reported." And he and others also warn that companies with a faulty program creating bad data may not realize it yet. Nevertheless, after this first week of the Year 2000 shakedown cruise, Hayes said it was hard not to see the results as good news."



-- pshannon (pshannon@inch.com), January 11, 1999

Answers

You know, for the life of me, I don't know why anyone would think this would be such great news. 1/1/99 has never (or should never) have been on anyone's radar screen as a really significant Y2K date. Calling the relatively minor public glitches "good news" seems something of a streth. I'm sure there were a lot more private problmes (ie, they happened in accounting software, etc, but were never seen by the public). That's fine; the public never sees most problems anyway, and any Y2K problems not seen by the public will generally be considered not to have been problems at all (which I think is a legitimate interpretation- after all, if the airliner has a problem in-flight that the passengers don't know about it, & it gets resolved & they never *do* know about it, then they will never have considered it a problem, so to speak).

So, there were only a "few" problems 1/1/99. Big deal. It's almost irrelevant.

DP/CBN News

-- Drew Parkhill (y2k@cbn.org), January 11, 1999.


I never expected problems on January 1, 1999 that would cause disruptions. I did think I would be hearing about some glitches, and that's what we had. It's a gentle reminder that Y2K is real. Most of the date glitches of the last 10 days were in software. Embedded systems in utilities, manufacturing and so on won't start having most of their problems until December 1999 and January 2000.

-- Kevin (mixesmusic@worldnet.att.net), January 11, 1999.

Aw, c'mon, Drew. You're a journalist. You should understand the purpose behind a story like this one.

The NYTimes is the "newspaper of record" for the global financial elite (and one of my local papers). They are charged with conditioning their readers with the attitude that capitalism, consumerism, and steady economic growth are the gods to be prayed to. By now, most of their readers are starting to hear more about Y2K and maybe coming to a few conclusions. They print stories like this in order to say "yes, there is a problem" and "no, it won't be that bad." It's propaganda, Drew, not reporting. (OK, so it's dressed up as reporting with some sources. Very carefully chosen and quoted sources.)

It certainly would not be in the best interest of the NYTimes, as an advertising driven publication to do ANYTHING to cause even a whiff of panic in New York over this issue. So, they propagandize. And frankly, nobody in NYC seems to give a damn anyway...

-- pshannon (pshannon@inch.com), January 11, 1999.


ps... you are right on!

This is pure propaganda... amazing. Here it is, January 11th and they're already saying "no big deal".

I never expected the kinds of problems outlined in the article so these "little glitches" are kinda frightening.

Gotta keep that confidence up!

Mike ===================================================================

-- Michael Taylor (mtdesign3@aol.com), January 11, 1999.


Agree with Drew and most everyone else. The big error was not only in focusing on 1/1/99 (and, let's face it, many doombrooders did) but even on many of the other expected 99 dates.

Bank on it (oops): the system will be able to absorb most/all Y2K lookahead stuff without significant problems going public at all. In other words, there will be anticipatory bell curve problems (the JAE effect is likely to be quite real, pace Cory) but the public won't see more than a few of them.

Now, Drew, your job, though remains one of digging below the surface so those of us who really do want ALL the news that is fit to print get it .....

-- BigDog (BigDog@duffer.com), January 11, 1999.



From, behind the scenes, July 1, 1999 looks to be a "key" date.

Diane

-- Diane J. Squire (sacredspaces@yahoo.com), January 11, 1999.


The real problem with seeing too much good news in this is that the article confuses two distinct problems, namey Y2K and the Y99 problems.

Y2K deals with the inability of some systems to properly handle dates after 1/1/2000. Y99 deals with the failure of some systems to recognize 99 as a valid year (either as 1999 or as 2099), thinking instead that an end-of-file or end-of-processing marker has been reached.

The two prblems have only two things in common. One, they both stem from using 2 digit year representations in date fields. Two, they are occuring withing a year of each other. The first makes them somewhat related, although they are still cousins at best. The second is just a coincidence of timing.

-- Paul Neuhardt (neuhardt@ultranet.com), January 11, 1999.


Paul, yes - y2k vs. 99 error codes in date field: they are 2 different things. But the '99 situation makes a general point that code is being remediated faster than expected, because software tools and methods, contrary to beliefs on our forum, actually HAVE improved over 30 years. And, second, as long as the power stays up, fix on failure IS possible, just as in the "fallen tree branch" analogy I posted a long time ago.

-RC

-- runway cat (runway_cat@hotmail.com), January 11, 1999.


>>From, behind the scenes, July 1, 1999 looks to be a "key" date. - Diane

Why? After seeing the Euro introduced so cleanly, I'm starting to think that software problems in major problems can be "glossed- over". If, in preparation for 1/1/1999, the systems could be made to look-ahead less than a year, why can't that be done for June too?

On the other hand, when I hear a rumor on WorldNetDaily indicating that the National Guard says that it is cheaper to build new oil refineries than fix old ones, I get even more worried about embedded controllers.

-- Anonymous (Anonymous@anonymous.com), January 11, 1999.


Paul,

Some Y99 problems have to do with "99" being an end-of-file or end-of- processing marker, but some are because of programs this year that are calculating dates past December 31, 1999. See Ed Yourdon's article "Y2K Software Projects; deja vu all over again".

http://www.yourdon.com/articles/y2kdejavu.html

-- Kevin (mixesmusic@worldnet.att.net), January 11, 1999.



We don't have to depend on the media to find out about what's happening along y2k foul ups.

I have not found nearly as many problems occuring as I had anticipated. It seems that neither has most anyone else.

There should have been a lot more reports about problems with checques, electronic gear, billings, resevations, etc.

But not much has been reported; especially in light of that only 8% of TS is supposed to hit TF on Jan. 1, 2000.

Am I too optimistic; or am I a mushroom?

-- fly . (.@...), January 11, 1999.


fly,

Maybe only 8% of SOFTWARE problems will happen on January 1, 2000, but I'm sure that most of the embedded system problems that impact infrastructure will be in December 1999 and January 2000.

-- Kevin (mixesmusic@worldnet.att.net), January 11, 1999.


Anonymous,

July 1st, 1999 ... because 46 states, etc. rollover, many are the least Y2K ready, it's the drop dead date to shut down non-compliant nuclear power plants (4 months with electricity needed to cool the cores), the military wants to be ready by then.

Other reasons?

Diane

-- Diane J. Squire (sacredspaces@yahoo.com), January 11, 1999.


July 1, 1999 gets my vote.

-- flierdude (mkessler0101@sprynet.com), January 11, 1999.

RC, you said:

"Paul, yes - y2k vs. 99 error codes in date field: they are 2 different things. But the '99 situation makes a general point that code is being remediated faster than expected, because software tools and methods, contrary to beliefs on our forum, actually HAVE improved over 30 years. And, second, as long as the power stays up, fix on failure IS possible, just as in the "fallen tree branch" analogy I posted a long time ago. "

I have frequently been branded on this forum as a Pollyanna, but even I can't agree that this shows that code remediation is proceeding faster than expected. I suppose that it is proceeding faster than those who said it couldn't be done expected since some stuff is being fixed. And yes, techniques and tools have improved a lot over the last 30 years. Heck, the difference in the last 10 years is staggering. And yes, I too believe that "fix on failure" is a valid method of addressing some Y2K issues.

But remember one thing: the incidence of Y99 problems is only a tiny percentage of the magnitude of Y2K. Using the so far small Y99 problem rate as a forcast for Y2K is too optimistic even for me.

-- Paul Neuhardt (neuhardt@ultranet.com), January 12, 1999.



Kevein, you siad:

"Some Y99 problems have to do with "99" being an end-of-file or end-of- processing marker, but some are because of programs this year that are calculating dates past December 31, 1999."

Not by the definition I used. Programs having problems with date calculations involving dates past 12/31/1999 are true Y2K issues, not Y99 issues. They only happen to occur in 1999. For more info, see some of the discussions regarding the so-called JoAnee Effect". True Y99 problems relate to the improper handling of dates in 1999.

-- Paul Neuhardt (neuhardt@ultranet.com), January 12, 1999.


Or "The JoAnne Effect."

Blast and damn Fat-Finger Syndrome!

-- Paul Neuhardt (neuhardt@ultranet.com), January 12, 1999.


'99 rollover glitches taken into account, we shouldn't forget the "other" 1999 problem, that of renovated/replaced compliant systems gone bad.

Here's an e-mail I got from Don Fowler who maintains a '99 glitch repository at http://www.mardon-y2k.com/page17.html, when I alerted him of the Senate chaos article.

"Thanks for the info.

We've seen more than a few of these. I experienced a similar fiasco at my bank! They moved to a new systems provider who is Y2K compliant. The first month of the new operation was a disaster. ATM cards that would not work because all of the PINS were changed, tellers that did not have a clue how to work the new system, help lines that never answered, and changes in the checking account provisions that cause many people to get service charges that they never incurred before. I'm not adding these to the defects report but will start a new report on Y2K project "gone bad"."

-- Chris (catsy@pond.com), January 13, 1999.


Chris,

the scenario you describe at the bank has the potential for occuring anytime there is a large-scale system upgrade/replacement. I suffered through a very similar problem with ATMs and teller transactions when my bank upgraded systems a few years ago.

To me, the Y2K issue here isnt't that new system implementations and conversions are problematic, but rather that there may be a higher number of such conversions occuring during this year than normal as many systems are replaced rather than remediated.

-- Paul Neuhardt (neuhardt@ultranet.com), January 13, 1999.


Mill ennium Bug Strikes U of A Early

January 13, 1999, Vicki Hall, Journal Staff Writer, Edmonton

Computer glitches are causing constant busy signals, long lineups and growing frustration a year earlier than feared at the University of Alberta.

An effort to head off the Year 2000 computer bug is at least partially to blame for the irritation among students trying to change their schedules for the winter semester, said U of A registrar Brian Silzer.

Some students tried in vain for hours to get through to the university's automated phone registration system this week. And when they finally got through, the system mysteriously disconnected them. The ailing phone system caused thousands of students to line up in person, some for up to four hours.

"I didn't even bother lining up last week," said Doug Culbert, a fourth-year student in Latin American studies. "It would have been a waste of time, because they were so big.

"There are lineups everywhere at this place."
The problem came after the university installed a new mainframe computer as it changes its registration system, said Silzer.

The university is making the switch in part to avoid problems with the millennium bug, Silzer said.
....
The new mainframe at the university turned out to be incompatible with the current phone system. That caused the system to malfunction, Silzer said.

Silzer apologized for the long waits on the phone and in person at registration headquarters in the Butterdome.

"We've had a rough ride," he said Tuesday. "Some students reported waiting in line for three or four hours, and that's not acceptable. "It's embarrassing."

Monday was supposed to be the deadline for adding or deleting classes without penalty for the winter semester. But the university changed the deadline to 6 p.m. today in light of the technical trouble. It also extended the hours for in-person registration.

"I just put the phone in my lap and kept re-dialing," said John Mekar, a fourth-year environmental science student. "I finally got through, but it moved really slowly."

Professors have also been frustrated with the delay in finalizing their class lists for the semester, Silzer said.
The registrar hopes students and professors won't have to suffer again as the transition to the new registration system is completed later this year.

"I'm crossing my fingers," he said. "There will definitely be growing pains.
"But I just hope we don't have any major hiccups like we've had this January where we've had to subject people to lengthy delays or confusion."
----------------------------------------------------------------
xxxxxxx xxxxxxx xxxxxxx xxxxxxx xxxxxxx xxxxxxx xxxxxxx xxx

-- Leska (allaha@earthlink.net), January 13, 1999.


Moderation questions? read the FAQ