The Forum is still buzzing about the Senate Report and the media's spin response. It is apparent to me that some people who may have woken up now, even briefly, can be approached about Y2K, or perhaps, will approach you for information. As I have posted over the months, we are the leaders. To a large extent, Y2K awareness is up to us.

This brings me to the Y2K failures list, created here on this Forum. Links to the list were posted by CBN on Friday (2/26), and then by Gary North on Monday (3/1). The whole point of creating the Y2K failures list was to offer it as "proof" to people who just don't get it, in the hopes that it will help them to take Y2K seriously. Now may be a window of opportunity to use the list, perhaps as a follow up or supplement to the Senate Report.

Assuming you know of some folks that just don't get it yet and that you want to help them, I ask you to consider using it. If you have already used it, please post what, if any, results there were.

Two Cents: I had several people in mind when putting the list together - leaders in the community. I gave them the list (minus comments) and two of the three read it and had positive reactions - though they were both already leaning towards getting it. I think the list did result in giving them an extra push and sense of urgency though, both from what they said and specific actions that they are finally undertaking. The third person is a serious Don't wanna get it. I have not seen this person since giving them the list so the jury is still out. There are also others that I have not yet seen that I intend to provide the list to. Realistically, I do not expect this list, nor anything short of a major failure or panic, to make a lot of folks get it - all I can do is hope it helps.

-- Rob Michaels (sonofdust@net.com), March 03, 1999

Answers

Rob,

I am going to re-post that list again this weekend, BTW. We are in the process of redesigning the Web page, and, if things work out, it will have a fairly prominent place on the site in the future. That's up in the air at this point.

-- Drew Parkhill/CBN News (y2k@cbn.org), March 03, 1999.

Here is a list of Y2k glitches from the "Oregonian" newspaper.

Y2K's already here when it comes to computer glitches Many big U.S. firms already have had online woes linked to the year 2000

Sunday February 28, 1999....By Steve Woodward of The Oregonian staff

Every Y2K junkie knows the story of 104-year-old Mary Bandar of Winona, Minn. In 1993, her Catholic parish sent her a surprise invitation -- to come to preschool.

Bandar, born in '88 (1888, that is), had been culled out of a database search for all Winona parishioners born in '88 (1988, that is). "Why would they want me?" she said jokingly to the Associated Press at the time. "I know the ABCs yet. And I can count to 10."

The database, which used only the last two digits of the year, couldn't tell the difference between 4 and 104 years old. It's the classic example of the Year 2000 computer problem.

It's also the classic reminder that Y2K won't really arrive at the stroke of midnight on Dec. 31.

Rather, Y2K is like a slow-motion train wreck, gathering speed as it clacks down the tracks toward 2000. Thirty years after it crashed its first computer programs, the millennium bug is sweeping a widening swath of mischief in offices, schools, factories and city halls from Portland, Maine, to Portland, Ore.

Missed paychecks. Incorrect sewer bills. Vanished data. Garbled reports.

It's not the end of the world as we know it...But the trend is unmistakable: Y2K is already here. ---------------------------------------------------------------------- ---------- 1995.

Portland, Maine. Unum Life Insurance Co. deletes 700 broker records from a licensing database after a computer mistakes "00" for 1900. Records are restored in several days from backups.

1996.

South Island, New Zealand. At midnight on New Year's Eve, 660 process control computers at the Tiwai Point aluminum smelter go dead without warning, causing $1 million in damage. The computers, which tell time by counting the number of days in the year, had encountered an "impossibility": the 366th day of the year. They didn't know 1996 was a leap year.

1997.

Sterling Heights, Mich. Chrysler Corp. rolls clocks forward in a Y2K test of an automobile assembly plant. The security system immediately shuts down, locking workers inside the building. ---------------------------------------------------------------------- ---------- The Year 2000 problem has lain largely dormant since 1969, when engineers scrambled to fix programs that had begun miscalculating 30-year mortgages and bonds. But the pace of failures has begun to increase.

A year ago, 7 percent of large U.S. corporations and government agencies had experienced a Y2K-related failure. Today, the tally has leaped to 55 percent. That's according to quarterly surveys by New York-based Cap Gemini America, one of the world's largest computer services consulting firms.

Since the beginning of the year, Y2K-related glitches have caused taxi meters in Singapore to go dead, locked employees out of a New York insurance company office, triggered the early release of sensitive U.S. Labor Department data onto the Internet, collapsed the class-registration automated phone system at the University of Alberta, snarled the U.S. Senate's bill-paying system and inadvertently activated the Monkey V computer virus, which had been waiting quietly for the arrival of the year 2000.

Closer to home, date-related computer bugs have blitzed the Portland Water Bureau's inventory system, halted Washington County's fiscal year budgeting and caused a state government computer to spit out nonsensical numbers for an insurance report. ---------------------------------------------------------------------- ---------- Oct. 1, 1998.

A Year 2000 failure was the furthest thing from Robert A. Nies' mind when he noticed a routine report that was loaded with bogus numbers.

"We got numbers that were way off. I noticed it immediately," said Nies, a financial analyst with the state of Oregon's Risk Management Division.

The first quarter of the state's 1998-99 fiscal year had just ended the day before. As he has done every quarter since November 1996, Nies ran a so-called self- insurance reserve report, which shows the state's reserve strength in its property, liability and workers' compensation insurance accounts.

"I ran the report three times," he said, "and it was giving me junk."

Two days later, a state computer programmer found the culprit: the millennium bug.

The program used a quirky approach to indicate the end of a report. It always began with the year 1981 and used simple addition to tell it when it had reached the current fiscal year.

Unfortunately, the program recognized only the last two digits of the year. So when it added 1 to the fiscal year '99, it got an answer it couldn't compute: 00.

The programmer patched the problem long enough for the Department of Administrative Services to install a new system, which was switched on Feb. 1.

"The funny thing was," Nies said of the old system, "it was supposed to be Y2K- compliant." ---------------------------------------------------------------------- ---------- The Year 2000 computer problem isn't new to Portland.

Two years ago, the Portland Water Bureau's inventory management system failed when it projected ahead to 2000. Programmers installed a temporary fix, so the bureau could continue to manage its central supply warehouse. The program will be replaced with certified software in April.

On Jan. 1 this year, at one minute after midnight, a Portland delivery company went into emergency mode when several order-entry programs crashed. A technician from its software vendor logged onto the system for four minutes and fixed the problem without volunteering an explanation. Later, the delivery company's system administrator, who asked for anonymity for himself and his company, later traced the crashes to an expiration date the vendor had forgotten to remove after Y2K testing.

At the same time, across town, a financial services company's data center experienced five different failures involving a handful of transactions in four old mainframe applications. One program, for example, began spewing out 1999 paperwork showing 100 years' worth of payments due.

Fortunately, the company's information services staff was already standing by, watching for Y2K-related failures -- going so far as to monitor the power when midnight hit the leading edge of the Western power grid at 10 p.m. Pacific Standard Time.

"Everything was trapped in the data center," said the company's Year 2000 project manager, who, like many other private-sector Y2K managers, spoke only on the condition that neither he nor his company be identified to avoid potential legal liability. Of the errors, he said: "Nothing crashed, nothing burned, nobody died, no customers were impacted by this."

The problems were traced to human error. Some employees had ignored managers' instructions to handwrite such information as renewal dates, throw them into customers' files and input them after the systems were repaired. Instead, they typed "00" into the non- compliant programs, which interpreted the digits as the year 1900. ---------------------------------------------------------------------- ---------- Jan. 4, 1999.

Employees in the Washington County Sheriff's Department encountered something odd and maddening when they came back to work after the New Year's holiday: The county's crime statistics reporting database refused to accept any date beyond 1 2/31/98.

The program supplier had built the database 10 years before, using four-digit years. He had declared it Year 2000-ready.

Which it was -- except for one thing: He had put a 10-year expiration date into the program.

The problem was fixed by the next day.

"It did not affect any community activities. Nor did it represent any health and safety issues," said Wayne Horscroft, site manager for Unisys, an information services contractor for the county. "Just held up the collection and representation of monthly crime statistics - - annoying but really quite a ho-hum sort of situation."

Two months before, Horscroft said, the county's budgeting system had refused to allow new data entry into the fiscal 2000 budget.

The database, hardware and operating system had proved Y2K-ready in early 1998 tests. The system didn't rely on either four-digit or two-digit years for its calculations. Instead, it told time by counting the number of days before or after the date Dec. 31, 1967.

"Very simple and very effective," said Horscroft, who went to work for Unisys after taking early retirement as manager of PacifiCorp's multimillion- dollar Y2K project.

But a problem lurked in the budgeting application code's "weeds."

The original programmer called for the computer to abandon the usual date format when it created the identity of the current fiscal year. So the current fiscal year, for example, which began July 1 and will end June 30, is identified as 98-99.

So far, so good.

But the programmer also called for the computer to add 1 to each number of the fiscal year identity to create the new fiscal year.

That caused fiscal 2000 to be identified as 99-100.

The result: immediate disruption.

"It took about three days to locate the offending routine, clean it up, test it and then put everything back into production," Horscroft said. ---------------------------------------------------------------------- ---------- Last year, engineers at PacifiCorp, which operates Pacific Power and Utah Power, ran a Y2K test of three power-generating units at a Utah power plant.

PacifiCorp's supplier had certified the units as Y2K-compliant. But the supplier had actually tested only one of the units, assuming the other two were identical. They weren't.

As soon as engineers rolled the clock forward to 2000, two of four control monitors went blank.

Peter de Jager, a computer programmer best known for his "Doomsday 2000" article, published in Computerworld in 1993, calls such failures "evidence of effort."

In a January article on his Web site (www.year2000.com), de Jager contends that anyone who is truly fixing a Year 2000 problem will have a failure to show for it.

"Ask them what they found which would fail and what they've done to fix, replace, or work around that failure," he writes. "If you haven't found a Y2K failure, then either you're not working on the problem, or haven't looked hard enough." ---------------------------------------------------------------------- ---------- Steve Woodward covers the Year 2000 computer problem. He can be reached at 503- 294-5134 or by e-mail at stevewoodward@news.oregonian.com.

-- Laurane (familyties@rttinc.com), March 03, 1999.

Drew: I am thinking about making a new thread that has just the list of failures in it (without comments as we originally discussed) so that folks can just print it out without having to do a lot of copy/paste/cut. What do you think of this idea?

Laurane: Thanks for the additional info from the Oregonian. Can you or anyone provide links to the articles?

-- Rob Michaels (sonofdust@net.com), March 03, 1999.

Rob,

That's fine with me. You could simply start the thread by saying "Please do not post comments here" or something like (although who knows what would happen in response to that). Or you could do a list of separate threads, which I could cut & paste, and thereby ignore any comments which appear after your examples... Let me know what you think...

-- Drew Parkhill/CBN News (y2k@cbn.org), March 03, 1999.

ROB !!!!!!!
I've linked & copied that List several times on various threads, puttin your name on it too ;-)

Portland isn't afraid of telling the facts - article on front page of the Oregonian

List of Y2K failures - Here is proof

xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxx

-- Leska (allaha@earthlink.net), March 03, 1999.

Drew: I'll do it that way - sounds good. I am really busy lately so probably won't get to it immediately, but should have it by Friday morning for you, and will post to this thread to let you know.

Leska: Thanks - I havn't read that thread but will now (or soon anyway) and will include the info on the new list. Hope to have some time late tonite for this stuff but don't know yet. I need an FRL and circus break too!

Forum: If you have used the list please post to this thread. I will check in again late tonite, Rob.

-- Rob Michaels (sonofdust@net.com), March 03, 1999.

Rob,

Here's a failure you might have missed. It was posted on a thread yesterday but buried deep:

Remarks from Republican Senator Kit Bond on the floor of the Senate, March 2, 1999, during a debate on the SBA small business Y2K loan bill

A good example of how small businesses are dramatically affected by the Y2K problem is the experience of Lloyd Davis, the owner of Golden Plains Agricultural Technologies, Inc., a farm equipment manufacturer in Colby (sp), Kansas. Like many small business owners, Mr. Davis business depends upon (trailing?) technology purchased over the years, including 386 computers running custom software. Mr. Davis uses his equipment to run his entire business, including handling the companys payroll, inventory control, and maintenance of large databases on his customers and their specific needs. In addition, Golden Fields (possible mis-speak on Bonds part--he may have meant to say Plains.) has a Web-Site that sells the farm equipment it manufactures over the Internet. Unlike many small business owners, however, Mr. Davis is aware of the Y2K problem, and tested his equipment to see if it could handle the year 2000. His tests confirmed his fear. The equipment and software could not process the year 2000 date, and would not work properly after December 31, 1999. Thats when Mr. Davis problems began. Golden Fields (I dont know if this is supposed to be Fields, or Plains, since Bond has referred to both names) had to purchase and upgraded software package. That cost $16.000. Of course, the upgraded software could not run on 386 computers. So Golden Fields had to upgrade to new hardware. Golden Fields had a computer on each of its eleven employees desks, so that each employee could access the program that essentially ran the company, and assist filling the Internet orders the company received. Replacing all the hardware would have cost Golden Fields $55.000, therefore--a little quick mathematics--we find that Golden Fields needed to spend $71,000 just to put itself into the same position it was in, before the Y2K problem grew on him. Like many small business owners facing a large expenditure, Mr. Davis went to his bank to obtain a loan, to pay for the necessary upgrades. Because Golden Fields was not already Y2K compliant, his bank refused him a loan because it had rated his companys existing loans as high risk. Golden Fields was caught in a clear Catch 22 situation. Nevertheless, Mr. Davis scrambled to save his company. He decided to lease the new hardware instead of purchasing it, but he will pay a price that ultimately will be more expensive than conventional financing. Moreover, instead of replacing 11 computers, Golden Fields only replaced 6 at a cost of $23,000. Golden Fields will be less efficient as a result. The experience of Mr. Davis at Golden Fields has been and will continue to be repeated across the country, as small businesses realize the impact the Y2k problem will have on their business."

Hope this helps.

-- FM (vidprof@aol.com), March 03, 1999.

Rob,

If you don't get it done by this weekend, don't worry. I have plenty of stuff already (probably too much). But if you do, fine.

BTW, here's another one you may have already used (don't remember):

Problems lurk in more than just computers Milwaukee Journal Sentinel Feb 14, 1999

http://www.jsonline.com/bym/tech/0214chips.asp

*Tava Technologies, a Colorado software and consulting firm that specializes in assessment and repair of plant Y2K problems, says that in its experience at more than 400 sites, it has "yet to find a single site that did not require some degree of remediation (repairs)."

*At a pharmaceutical firm with operations in 39 countries, for example, Tava found 4,457 embedded processors in the laboratory equipment and manufacturing facilities of one location.

*Based on an inventory it conducted, 18% of the items were not Y2K compliant and 17% could cause a plant shutdown or affect production.

*"The chance of these systems failing was 70% for the lab and 80% for manufacturing and facilities," says Bill Heerman of Tava's Denver office.

*Tava estimated that it would take 39 weeks to inventory and analyze the firm's 125 plants at a cost of $11.5 million. The fix would take another 31 weeks and cost $54.8 million.

-- Drew Parkhill/CBN News (y2k@cbn.org), March 03, 1999.

Nice to see you here Drew! Per your post, TAVA has reported that at one site: "Based on an inventory it conducted, 18% of the items were not Y2K compliant and 17% could cause a plant shutdown or affect production." SO, almost all y2k bugs found caused a major problem, and very few were minor. Interesting, exactly opposite of what I have found, even in laboratory equipment since my findings are that most devices will continue to perform their functions with very minor date problems.... but then, I don't have to drum up the next Y2k job...;)

Regards, FactFinder

-- FactFinder (FactFinder@home.com), March 03, 1999.

FM: Interesting 'testimony' - if I can find a link to the SBA debate it would make a good addition to the list.

Drew: I will add the failures from the Milwaukee Journal Sentinel, as well as some other new ones. Looks like I can still shoot for Friday if tomorrow isn't too busy - I will post to this thread letting you know when it is ready - no hurry on either of our parts. (nice for a change, huh? :)

BTW, I'll create all of the hotlinks for the sources on the thread if you want. Let me know if it makes sense to do this or not.

-- Rob Michaels (sonofdust@net.com), March 03, 1999.

Fact: it depends on how you define "minor" (as in, "very few were minor")- that depends on what the impact of "affect production" was. Be careful of impugning motives :) 17-18% under certain circumstances (and that's the key) is probably not unreasonable. One Aussie or NZ hospital reported that one-third of its devices had Y2K failures from embedded systems, if memory serves. Yet other hospitals have reported neglible failure rates (these were the hospitals, not the device manufacturers, in both cases, as I recall). So wide variances of failure rates- allowing for high rates in some exceptional cases- is not inconceivable.

Rob: Hotlinks would be great, if you can get it done. Whatever you think is best; I'll just frame your stuff & take it from there.

-- Drew Parkhill/CBN News (y2k@cbn.org), March 03, 1999.

Drew: I should be able to finish up the work and have the new list ready for you tomorrow morning, and will post a message to this thread to let you know when it is ready. I won't actually post the new list until you let me know that you are ready to grab it, ok?

-- Rob Michaels (sonfodust@net.com), March 04, 1999.

Rob,

I'm ready when you are!

-- Drew Parkhill/CBN News (y2k@cbn.org), March 04, 1999.

Drew: 8:50 a.m. est - it is ready. I will begin to put it all on a new thread called "READ ONLY - Y2K Failures List - Please do not post to this thread" and will do the hotlinks now. This make take a while.

-- Rob Michaels (sonofdust@net.com), March 05, 1999.

Rob,

Okay, I'll be looking for it.

Drew

-- Drew Parkhill/CBN News (y2k@cbn.org), March 05, 1999.

Drew: I had to break up the list into two threads since I maxed out the buffer (on each) and as a result, could not get the last failure in the second thread (I would have to had started a third!). The one that didn't get in was the one from the Milwaukee Journal Sentinel that you told me about. Perhaps you can add this one yourself if you want. The hotlinks look like they work - I spot checked them :)

Please continue to post comments to this thread if you have any. Rob

-- Rob Michaels (sonofdust@net.com), March 05, 1999.

Rob,

They're up on the (CBN) site. My thanks. Don't worry about the last one (from the JS)- we had a bit of a discussion about it on the euy2k forum (Rick Cowles); it was a question of whether or not it should be considered a "fact" since it was not first hand (although someone else posted a first-hand report, similar to the JS story, from the UK). Keep up the good work. Let me know when the next one is ready :)

-- Drew Parkhill/CBN News (y2k@cbn.org), March 05, 1999.