from todays c.s.y2k:

What? What! I say, Wha?

On Wed, 30 Dec 1998 22:09:23, rayl@whc.net (Ray Leseth) wrote:

> FDA warns Y2K bug may strike early > > Wednesday, 30 December 1998 15:27 (GMT) > > (UPI Spotlight) > FDA warns Y2K bug may strike early > WASHINGTON, Dec. 30 (UPI) - The Food and Drug Administration is > warning hospitals and other medical practitioners (Wednesday) that the > kind of computer bugs expected to cause problems on January 1, 2000 will > affect some medical devices this New Year's day. The FDA has confirmed > certain brands of defibrillators and patient monitors will function, but > will not be able to record the date and time of the device's operation, > once the calendar switches from 1998 to 1999. > > Copyright 1998 by United Press International > > *** Posted from RemarQ - http://www.remarq.com - Discussions Start Here (tm) ***

Can't record the date when the calendar swiches from 1998 to 1999? I don't understand this one and I'm the Y2K hypester who some people say invented the "it's gonna happen at the end of 1998, not 1999" concept.

Remember the April fool essay about how Un*x or was it the C language was just a practical joke?

I was thinking about writing a piece about how Jo Anne was really a 20 year old English major at Yale and had fabricated the entire Jo Anne Effect after a Rave; but no, that would blow things all out of control.

Here's the problem, I know why accounting systems will fail when the end of their fiscal year crosses the 1999-2000 boundary. I worked the circumstances under which some very poorly written systems will touch the wall in December 1998.... and took heat from certain people until I clicked on "Rejection Filter".

We've gotten several reports of "the December Effect" which someone email'ed me that a c.s.y2k wag as named "cory's folly." Well, I am clueless.

My guess is that less that a few percent of year long date bounds will touch the wall in December 1998. And this is for accounting and batch type systems.

In this case, I am clueless because I sure don't know why a defib's logging device would fail on the 1998 to 1999 roll over. This is stranger and more wonderful that I had imagined.

Listen up people. Stuff is failing in ways that I didn't anticipate.

TIMES UP

This is no longer a debate about "whii-iine, you didn't prove it to my thick-headed satisfaction." nor is it "harumph, I write op-ed pieces in newspapers and that qualifies me to comment on technological issues even though I don't know how refrigeration works."

This is especially not "I think paul milne and Gary North are hyping the problem because, uh, well, I don't like it, so there!"

RULES CHANGED.

For a real programmer, it's extremely scary and frustrating when it doesn't work like you think it should. I want to see the source for the defib software. I gots to know.

I want to drive over to where these things are made, grab the chief embedded programmer and s-s-s-shake him s-s-s-silly. S-s-s-slap him around.

What's going on? How many other things are failing?

Please denial butt-heads, use your big brain and tell me what the hell is going on. A defib is a device that can save lives or kill. How the hell does a software flaw get past QA? It's got to be exactly right, perfect, 100 percent. How can any failure occur? Any. And why is this uncovered now, Why is the FDA telling us now, the end of December 1998?

This is incredible. This is beyond understanding.

You know how some people are fussy about how clean their kitchen is or dirt in their car. They want things just right. That's how you're supposed to be with biomedical devices that attach to human beings and deliver lethal voltages. Everything is supposed to be absolutely perfect, none of it should be... ah, that's good enough, they'll figure it out in the field, I'm going home.

I can't tell you how odd this strikes me. Maybe I better take a stress pill, hang with some buds at the pizza place.

cory hamasaki 366 Days, 8,788 Hours. -- I haven't put WRP 106 online yet, I'll be sticking the print version in envelopes tonight. Thanks everyone for being patient. I should have enough reprints of the 80 year old gardening book for everyone. 

-- a (a@a.a), December 31, 1998

Answers

OK, so Fix On Failure isn't the perfect solution.

-- Tom Carey (tomcarey@mindspring.com), December 31, 1998.

Oh come on - the warning says the logging screws up - nothing else. If this sort of thing is as bad as it gets I am just fine. Does sound curious tho - why would the logging be looking a year ahead? Unfortunatly, a lot of medical devices are not as well designed or built as industrial devices made for the same general purpose. Never have been sure just why - but it is a fact.

-- Paul Davis (davisp1953@yahoo.com), December 31, 1998.

# # # 19981231

"Cory":

Just goes to show ya! Even the brightest can't imagine the worst case "box" that the human specie is capable of creating.

I, too, would be interested in seeing the "spaghetti code" that created this scenerio.

The geek that created those defective defibs won't be "talking" about their foibles. Lawyers, insurance companies, and inept bureaucrats will see to that!

The release/notice _did specify a "work-around;" turning the clocks back to 19... er, "97" will do it. It's nothing "fatal." Only headaches for the legal shysters in the courtrooms.

Hang in there ... It can only get worse! ;-)

[ Do _you believe Deano's "testimony" in the "mortgage" thread! The mortgage firm I did the work for was in Michigan, with offices in Florida! ... He! He! He! ... "Happy New Year!" ... It'll be an interesting one; that's a SURE BET! ... Who do you trust?!? ;-) ]

Regards, Bob Mangus # # #

-- Robert Mangus (rmangus@mail.netquest.com), December 31, 1998.

Yesterday the Drudge Report was boldly headlining this article:

FDA Warns Y2K Bug May Strike Early

Wednesday, 30 December 1998 15:27 (GMT), (UPI Spotlight)

WASHINGTON, Dec. 30 (UPI) - The Food and Drug Administration is warning hospitals and other medical practitioners (Wednesday) that the kind of computer bugs expected to cause problems on January 1, 2000 will affect some medical devices this New Year's day. The FDA has confirmed certain brands of defibrillators and patient monitors will function, but will not be able to record the date and time of the device's operation, once the calendar switches from 1998 to 1999.
------------------------------------------------------------------

Knowing full well how busy, stressful, and entrenched hospital floors are, I'd say this is short notice. It will be difficult to pass this info along to all the Drs, RNs, Therapists, etc. who need to know. The fax machines on floors spew out announcements continuously, which gather on the floor until a harried nurse tosses them into trash. No time to read the things! No time to check eMail or snail mail box. No time to go to staff meetings. No time to chart completely! Barely time to make rounds.

Equipment printouts are put into an uncategorized "In" box which is sorted later, usually by an exhausted 'float' secretary, and filed ACCORDING TO DATE & TIME. Weird stuff that doesn't make sense is thrown away; there's so much of that. There will be problems. I know. I'm the one who *did* this stuff throughout a big hospital very recently. They don't have a clue about Y2K or related snafus. And they don't want to know. Attitude of "It's not my problem."

Don't get seriously sick for the next two years.

Ashton & Leska in Cascadia, been there done that
xxxxxxx xxxxxxx xxxxxxx xxxxxxx xxxxxxx

-- Leska (allaha@earthlink.net), December 31, 1998.

# # # 19981231

Paul Davis:

Probably not "looking ahead." Probably stems from a "special feature" that's triggered by "99" ( year ) code that "only exists in mainframe applications and devices" ... NOT! Ha! Ha! Ha! ...

Some geek probably "overloaded" the functionality of the data element to conserve on/extend limited RAM availability, etc., "stuffing" a "99" _temporarily_ for some other specified function. Most of those devices had/have very little ( 2Kb, 4Kb, 8Kb, ... 16Kb ) RAM in them ... to "contain costs!" Bean counters get in the way of "doing the right thing," too!

My $0.02 ...

Regards, Bob Mangus # # #

-- Robert Mangus (rmangus@mail.netquest.com), December 31, 1998.

I can see that from here on out, a lot of the discussions are going to be lost on people like Paul.

The point of the post is not that a crummy log file got screwed up, the point is that the systems are failing in wierd and mysterious ways. Like the ways we software types see when we are alpha testing. This is beyond scary that it is happening in "Y2k compliant" production gear despite the stringent safeguards of medical device manufacturers!

And Paul, before your credibility is completely destroyed, please retract that crap about QA being better for chips that control conveyer belts than for software that restarts human hearts.

-- a (a@a.a), December 31, 1998.

Paul- Thanks for verifying a's point. You are absolutely correct that the safety and operation of the difibrillators is not affected.

Your inability to explain why such a device would look ahead is the crux. Anticipating the illogical is much harder than anticipating the logical.

For too many years, simply too many devices in too many systems with too many boards programmed in too many special-purpose languages stored in too many ways with too little documentation are going to do too many different things one year from now.

I think I've said this too many times.

-- PNG (png@gol.com), December 31, 1998.

BINGO Mangus...

Revolution 9 (Lennon/McCartney)

(Collection of sound clips)

Number 9, Number 9, Number 9........

MoVe Immediate

-- MVI (vtoc@aol.com), December 31, 1998.