Our team saw two embedded failures this week, even with 75%-80%of the plant shutdown for a normal winter inventory adjustment.

Why did they fail on 1-4-2000 and 1-6-2000 and not on 1-1-2000? I think there are a number of reasonable answers.

1. A large % of the embedded chips that are sensitive to roll-over failures were shut down anywhere from a day to a week before roll-over. They are now on-line and are truly timebombs waiting to go off. That is one of the reasons for the increasing level of failures we are seeing now.

2. Many embedded chips in control devices (PLC's, loops etc.), perform sequencing type events or process sequencing type batch jobs (shutdown a process, up-date a loop, change op modes etc.) but they do this only at specific times. An embedded system in your process may look like it's OK right now, but when it's called upon to do it's thing it can't, or gives the wrong info. because its really lost it's mind. (program). These sequencing type events may happen hourly, daily weekly monthly or yearly, or any combination therof.

3. The failures I've mentioned above were at the low to mid level with respect to seriousness. No lives were in danger although it compromised a process and will cost the company >$60,000 to fix. This news you will never read about in the Wall Street Journal or see on the evening news, why.... because with the current rulings in Congress, the Insurance and potential liability issues, any company would be foolish to release such information. If and when it does get out it will be... "Not Y2K related".... count on it!

Don't want to be, but remain a "Doomer"

Please feel free to trash, spam or troll this post. The truth will be seen by all, Pollies, Doomers and all inbetween. Like I said before...Reality is a hard place to visit.

-- Poll-Morphic Doomer (greenem31@aol.com), January 09, 2000

Answers

Most embeddeds haven't even been run yet. We won't know the true effects for months, if not years. Stay prepped!!!

-- (quantel@sirvey.net), January 09, 2000.

Yo, Poll-Morphic Doomer!

Pray tell, what kind of plant is this? What do they make?

Thanks for the post!

Peace,

Don

-- Shimoda (enlighten@me.com), January 09, 2000.

thanks so much for a very helpful post. our govt client hasn't let our y2k hotline team go yet and i guess i am wondering why? i just hope medical devices with chips have errors in the future. i hope we would have seen them already.

is part of what you are also saying, is that certain gauges, etc. won't go off for a long time because a particular level or reading hasn't been breached yet???

-- tt (cuddluppy@aol.com), January 09, 2000.

PMD:

Surely with hindsight we can be very explicit about important details. You saw two embedded failures in one week. But you are very careful to avoid saying they were actually diagnosed as being caused by genuine date bugs. Were they? Do you know the failure modes? I'm NOT trying to say date bugs didn't cause the failures, but I'm suspicious when you don't say they did. Your "explanation" seems no more than an unsupported generalization. Can you give examples someone can verify?

You say "we" are seeing an increased level of failures. Are you speaking generally, or do you mean that 2 failures in one week is higher than normal for your facility? Have you ever had two failures in one week before?

Whether the failures are claimed to be y2k related or not (for insurance or PR reasons) is beside the point. The important thing is the lost productivity. In your case, it sounds mild.

In another post, someone claimed a "y2k PLC" failure shut off water in part of a hotel, yet it wasn't reported. And again, this poster didn't give any details like how he found out, who did the analysis, how long the outage lasted, etc. Like yours, his post (without such details) seemed no more than a feeble effort to claim the "truth" is being hidden from us.

The time for this has passed. We now know what failed and precisely why it failed. We need to give this information. Please.

-- Flint (flintc@mindspring.com), January 09, 2000.

My brother in law is a V.P. at a medium size manufacturing company. 2 of their production machines have crashed. They are waiting for logic boards from Germany. Causing a production backlog now. Nothing will be in the media about this. Hope they get those boards.

-- billy d (billyd@aol.com), January 09, 2000.

An embedded system in your process may look like it's OK right now, but when it's called upon to do it's thing it can't, or gives the wrong info.

Good point. Flint?

-- Should we put embed issue to bed? (@ .), January 09, 2000.

Hey, Flint ! What about the post under yours by billyd ? These are mother boards . Jump on that one ( or go suck a lolly pop ! Eagle

-- Hal Walker (e999eagle@freewwweb.com), January 09, 2000.

I don't understand the apparent animosity towards Flint.

But then, as it turns out, I don't understand much about y2k. That's why I'm still here.

-- Me (me@me.me), January 09, 2000.

Thank you Flint.

Poll-Morphic Doomer:

You state:

"This news you will never read about in the Wall Street Journal or see on the evening news, why.... because with the current rulings in Congress, the Insurance and potential liability issues, any company would be foolish to release such information."

I have not followed all the details about legislation passed WRT to Y2K, but if I understand you correctly, for some reason the laws passed essentially make it a liability to report a y2k issue as such.

It would seem to me that that the laws passed have more to do with just limiting liability. I see no reason why liability can not be limited even if the item is reported as a y2k issue.

It seems that the laws have the deliberate effect of coercing the corporations into stating "its not y2k", "its not y2k", ad nausem as we have been hearing.

For those not "conspiracy" minded, let this be a plain example that you don't need a "conspiracy" to get vast number of people to cooperate with you, you just need to pass some laws that make it illegal for them *not* to cooperate with your agenda.

BTW on thing I am confused about, if the companies offically say the problem is not y2k related, then how can they get protection from the y2k liability laws. It would seem to me they can't, and the insurance companies are going to be handed the liability bill. But the insurance companies are not dummies and are going to go through the companies with a roto-rooter to prove it is y2k related (which shouldn't be too difficult) so they don't have to pay up.

That's why I made stated in Ladies and Gentlemen: I now declare games of post Y2K era offcially open that:

POWERSPIKE IN CONNECTICT ANGERS RESIDENTS.

"Local community in Old Saybrook, CT suffered a major power spike Monday morning. TV's, computers, boilers, telephones... were blown out in numerous homes. The residents want to know - WHO'S GONNA PAY???!!!"

My Reply:

I now declare games of post Y2K era officially open. Gentleman take your positions. Coming in from your left expert programmer witnesses at the insurance companies and coming in from your right the expert programmers at the y2k compliant corporations, and in the middle, everybody else.

On your marks, get set, go...

Folks this is where the action is going to be I believe.

Comments?

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

Should and Hal:

Such problems are entirely possible. We always knew this. Now the question is, how common are they, what damage is done, and how soon are they fixed? The answers so far seem to be: Rare, minor, and quite soon.

These symptoms appear to be the reason why problems have been so insignificant so far -- both their frequency and their impacts were way overblown. NOT their existence; they clearly happen. Just their importance.

As for the media not running around reporting every little temporary production glitch, why should they? These small everyday problems have never before been considered within the scope of "news", and if they were they'd fill the entire newspaper, and would have for the last couple of decades. Most of the media's audience, face it, aren't trying desperately to create the misimpression that failed expectations didn't fail after all.

-- Flint (flintc@mindspring.com), January 09, 2000.

Flint The failures on these devices are without a doubt due to a date/time stamping error. When looking back at the whole embedded issue my understanding was that a roll-over from 99 to 00 on a date sensitive device could have one of three effects.

# 1 This was no effect, that is the device while date/time sensitive would simply roll without corrupting the time stamp or its ability to function a sequencing event. The RTC did not have to verify system date/time compliance and the 00 was not a fail event trigger.

#2 The RTC on the device would reach 00 from 99 and consider this system failure mode. In some cases this meant shutting itself off, or continuing to function in a limited capacity. Consider most computers made before 1995. If the CMOS battery died, the RTC (and its1 bit secondary clock) had no clue what the date was but defaulted to 00. The BIOS having a 1980 or other date depending on manufacturer tried to relate to the 1900 date and could not because it could not recognize a date prior to it's own program date. Try typing a date of say 1973 (at the DOS prompt) into a PC see what happens... "Invalid date". The computer doesn't explode (like many Doomers expected) it just won't boot until you go into the CMOS and manually set the date. It is this scenario that caused the doomsday scare, and it was always an unknown. One of those things that has low probability of happening but if it does can cause major ,major problems. This of course as we know now did not happen large scale, although my bet would be that some of the early "not Y2K related" stuff really was a embedded roll- over effect.

#3 This was, and is my major concern with respect to embedded chips/systems. It is in a way the same effect that could bring many financial systems to their knees in the next couple weeks. Bad data. Let us say that a process system that uses a high degree of embedded technology to function. In this system the process uses a multitude of feed-back information/control loops etc. to do what its intended to do. It really doesn't care what the real date is, but it still uses this time stamp information to process sequencing or programmed events. So we cross the roll-over, the chip fails but the system continues to act normally, except for one minor detail, instead of putting .01% NaOH into the flow it puts 10% because at xxxxhrs 10% should go in and it really doesn't know any more one program event from another- or "it's lost it's mind". If this is a chemical plant at some point in a day, a week, or a month later the wrong amount of ingredient "A" goes into the wrong amount of ingredient B and we end up with a mini TMI. A lot of the failures we are seeing right now are related or a function of this type of event.

Ps I would love to be able to give specifics (make/model, etc.) but will wait until the devices have been evaluated by the manufacturer of said device. This is one of those cases of liability and I will not risk my 30 yr. pension for the sake of some empirical debate.gree

-- Polly-Morphic Doomer (greenem31@aol.com), January 09, 2000.

Insurance........ I am a manufacture of drug "x". In 1999 my Company claimed it was Y2K compliant. In the year 2000, my company, while making drug "x" mis- formulates this drug because my process un- knowingly fails (due to a Y2K issue) or a raw material from a non- compliant vendor isn't right. This drug goes out on the market and kills 10 people. If I admit to a Y2K issue, after 30-60 days I can be sued for a multitude of reasons (wrongful death, FDA violations etc. etc. etc..) Because my insurance company doesn't cover Y2K related problems... I go bankrupt. If I don't admit to Y2K problems my insurance company pays under normal liability coverage.... and they go bankrupt. That's a big diff. to me...

-- Polly-Morphic Doomer (greenem31@aol.com), January 09, 2000.

PMD:

Again, the questions are how frequent, how damaging, and for how long. I'm perfectly willing to accept that your problems have been caused by date bugs, and been an inconvenience. And that such events haven't been systemic and haven't caused more than isolated problems. I see no evidence of any snowballing. Just a bunch of troubleshooting.

As a footnote, your point #2 above is a mishmosh of almost entirely incorrect assertions. To point out a few: the BIOS doesn't set 1980, DOS does. An invalid date has NEVER prevented a PC from booting, under ANY BIOS. No BIOS *requires* you to enter CMOS setup to correct a date, and I've never heard of one that even warns of such a "problem". DOS does that. You can remove the RTC battery (and short across the cap to the RTC) and EVERY BIOS will still complete POST and invoke the OS. [I should mention that I've made most of my living in the PC BIOS world for the last 15 years].

While I do not know the details of your specific failures, your misunderstanding of what a BIOS does casts some doubt on the clarity of the rest of your understanding. For what it's worth.

-- Flint (flintc@mindspring.com), January 09, 2000.

The insurance scenario above was used as an example. I have never worked in the drug industry....ALthough in the 60's I thought I did.

-- PMD (greenem31@aol.com), January 09, 2000.

PMD:

I think what I posted in the following thread is why nothing happend during rollover and nothing (of earth shattering consequence) will with respect to the embeds. Exerpts follow.

Serious Question on Embeddeds

----- EXERPTS -----

After the rollover I put my brain in gear, rather than relying on the "experts" as I have done to now about what goes in the embeds. I'm not a hardware guy, but I went back and thought about my only hardware project from 20 years ago in university (back when memory was expensive).

Any thing that is in hardware that deals in time is going to use counters to determine when time has elapsed. They are not going to use dates because you have to use more memory to store it and then convert it to a number to do the calculations and then more memory to convert the number back to a date. So they'll count seconds or days. The point of storing a date calculation is know when a certain amount of time has passed. If you use counters (even thousands of seconds for many days) it is the simplest, cheapest, and bug free way to do that - regardless of date. Now some of the more fancy hardware that is newer may have some date functions for things like maintenance (since memory is not a problem now) that has been arbitrarily decided to be done at month ends rather than on a fixed interval, but my guess are those are very few and between.

Yourdon, I'm surprised you fell for this in such a grand way, you're supposed to be one the "experts" who investigated all this. Why Mr. CEO said all his teams were being sent home was because his clients along with all the other companies with embeds found out the above and realized that the "consultants" were swindling them by just investigating and investigating and investigating but actually doing very little else. I'm willing to bet that 99.999% of all embeds are like what I describe above. That's why the world could tollerate a 0.001% hiccup in the number of embeds out there and not blink at all.

I'm willing to bet if you turn on 99.999% of the systems with embeds there is no place to enter a date or even set one - after all I don't see every one of these systems with a keypad or keyboard to enter a date if the current date is incorrect. These systems are black boxes like your modem. Yes they track time (with a counter) not by knowing what day of the year it is. They don't care about dates they care about durations of time and days passing.

(snip)

I read the report (Embedded Systems and the Year 2000 Problem like you suggested, and here are my comments.

1) They suggest that there are 50b chips with 25m with potential y2k problems in critical systems that need fixing. This means that if they are coorect .05% of all chips is sufficient to cause some serious chaos. Well now that we have 20/20 hindsight we can assume that far less than .05% of the chips failed. So my .001% figure actually seems quite interesting although I was just guessing. (My guess is based on the fact there can't have been too many failing since we are still here with out any major hicup (even is a lot of stuff in the grid is running on manual).

2) The paras talking about using absolute time for relative time keeping and about its correlcation to y2k is in my opinion fundementally *wrong* for a number of reasons:

Yes, chips keeping absolute time can be used for relative time keeping events. But the key question is how is absolute time recorded in the chip. I am again willing to guess it is using counters in 99.999% of the chips for the reasons I gave above - its the cheapest and least bug free way to do so. Then those systems that need to have the counters convert to a real date, the counter is just interpreted as an offset of seconds, days, weeks (or what ever increment is being counted) from a known date to get a current date that will be used on a display (not in the calculations) for us humans. The GPS rollover problem was exactly this problem. They were counting weeks and the counter ran out at 1024 weeks (notice a number that is a power of 2 - for all non-computing types out there, any number that is a power of 2 always has special signficance in computing since they are binary coutning machines) and rolled over. The GPS week counter is just added to Jan 6.1980 (week 0000).

Similary the other embedded chips using absolute time will be doing the same thing. Those that are used for applications that need to present real date and time to us humans will add the counter to a known date. This could be set at manufacturing time, or more likely the known date is set with a keyboard/keypad or some interface at which time the counter is also set to 0. This is because unless you can guarnatee the chip has power since it was manufactured, the counter will have stopped and therefore the chip can not give accurate time.

For those applications that are using absolute time counters for relative, time, then the issue becomes a) when was the chip fired up with power so the counter starts off, b) what does the counter count (millisecs, seconds, hours etc.) and how big is the counter before it rolls over.

As can be obviously seen every absolute time based chip (weather being used for relative time keeping or real absolute time) will rollover at a different time (not necessarily in 2000 but depending on what is being counted, when the counter started and how big is the counter -- they could rollover tommorrow, 2 years ago, or 4 years hence. This has nothing to do with y2k and the rollover date has no correlation to y2k. Again just consider the GPS counter rollover as an *EXACT* example of this issue). The issue is that when they rollover (as GPS did in August 99) has the rollover been accounted for in the design so the application the chip is in can continue to work?

So as you can see, regardless of what is going on - relative time counters set back to 0 after a period of time has elapsed (as I suggested) or absolute time counters used for relative time keeping (as the article suggests) or even absolute coutners used for real date and time, Y2K is not an issue for these chips. They will only be using dates for output functions for humans. Their interal "date" calcuations are really just adding and subtracting the counters as like I said that is the most fool proof way of doing date and time calculations. To store date and time in the chip in human readable form is a headache as the chip then needs to convert the human readable date and time representation to numeric form for calcuation and back to human readable form to store in the chip.

Any chips that need to check if a certain date has occured, will not translate the counter to human readable form (as again that is a complex process), but rather when the date to be checked is first entered into the system it will be converted into the correct counter value for that date and stored as a number. The chip then just has a simple job of comparing its counter to that number to know if the date has been reached.

Therefore, the only chips that will have a y2k issue are those that actually store dates in human readable form right in the chip. I think there will be very few of those.

I'm not a hardware guy, I'm an experienced software person. But all the techniques that are used in hardware are programmed in software, and so although none of my software has been put into chips, everything that the hardware people do, we software people have done in our own programs when we needed to track time. So there is nothing special they do that we have not already done. I just didn't put this through my head until after rollover when I realized the whole embedded chip y2k issue was 99.999% nonsense. The bug never really existed there.

----- SOME RESPONSES RECIEVED -----

Interested Spectator, regarding the last thing you wrote, about the systems that track time, but could care less about the date, well my husband had said the SAME thing to me no more than a couple of weeks ago. And He was working on hardware years before getting into software. And I figured he was right, but I Still worried about those nuclear embeddeds. Because the stakes Were so high. And that was my main concern. That and the electricity going out. So right now I feel pretty good, but won't use all the preps just yet. I've learned a lesson that Boyscouts follow as a matter of rule. Preparedness is a good lesson, pure and simple. What I Really wish is that solar power would become economically feasible. That's where we need to be going anyway.

-- DB (tomG@h.com), January 01, 2000.

IS,

I happen to be one of those utility company Y2K project team members. We examined and tested over 6500 systems with embedded chips. About 95% of those turned out to be exactly as you have speculated - no date/time function or only elapsed time or day counting. However, until we did the testing, we had no way to know this. Most systems were put into service years ago with no documentation about how dates were caculated. We spent 80% of our money testing and documenting systems and only about 10% on remediation. As it turned out, there was only one critical system that would have failed and that would have knocked 15 megawatts off-line. Since we produce about 3000 megawatts on average, we barely would have noticed it. If we would have known this two years ago, we could have saved a lot of time and money but we didn't, and there was no way anyone could have known.

We told everyone we could find that there would be no problems with power on Jan 1. We told everyone we were Y2K ready. We set up a monitoring center because, although the probablityo f problems was very low, it was not zero. As it turned out, we were right and I'm happy. What disturbs me is that some people either never listened to us or assumed we were lying. We worked hard and that's one of the reasons we're all able to get on the net tonight and post messages.

Happy New Year to All.

-- (Someone@somewhere.com), January 03, 2000.

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

#1- When your computer is 1st booting it doesn't even know DOS exists. The computer uses the date in your setup file, which is written to CMOS (actually CMOS RAM). If the CMOS presents a date prior to 1980 in an older computer it shows a CMOS error and refuses to boot. I have done this many times on old computers, in fact when I read your post I went down to the basement and caused my good ole Digital HiNote 450 to show a boot error. I assume the date in setup cannot predate the system BIOS. I've never heard that 1980 is a DOS limitation In my example using a Digital HiNote Ultra 475 (which I have flashed) the date will go to 2073 if I type in 1973 in setup (CMOS). In DOS, you still get an invalid date. Explain this DOS 1980 limitation.

-- PMD (greenem31@aol.com), January 09, 2000.

Flint.. In thinking through the issue of why the Digital fails to boot when a pre-1980 date is shown. I guess it could be a DOS limitation. I always figured the 1980 was a BIOS issue, because thats what the manufactures always flash when you've got Y2K issues.

-- PMD (greenem31@aol.com), January 09, 2000.

PMD:

Glad to help. I'll try to be only mildly technical here...

[#1- When your computer is 1st booting it doesn't even know DOS exists.]

True. The PC goes through the POST (Power On Self Test), and then boots whatever OS it finds.

[The computer uses the date in your setup file, which is written to CMOS (actually CMOS RAM).]

Need to define "the computer" a bit more closely here. The BIOS makes no use of the date under any circumstances, except to store and recall it. And the BIOS doesn't care what's in the RTC at all, it just reads and writes registers. (Except some BIOSs do a range check to make sure the RTC is in decimal mode, and all BIOSs make sure the RTC is operating and not broken).

[If the CMOS presents a date prior to 1980 in an older computer it shows a CMOS error and refuses to boot.]

Negative. The BIOS doesn't care about the date. Depending on the BIOS, you may be required to enter Setup if the CMOS checksum fails, or if the battery has gone dead. In newer (compliant) BIOSs, if the year is equal to 0, the software-maintained century byte will be set to 20. However, I will say that in the olden days (1980's) there were a zillion BIOSs out there, so there may be exceptions I haven't seen. If the POST won't complete with an "invalid" date, this is a BIOS BUG!

[I have done this many times on old computers, in fact when I read your post I went down to the basement and caused my good ole Digital HiNote 450 to show a boot error. I assume the date in setup cannot predate the system BIOS. I've never heard that 1980 is a DOS limitation In my example using a Digital HiNote Ultra 475 (which I have flashed) the date will go to 2073 if I type in 1973 in setup (CMOS). In DOS, you still get an invalid date. Explain this DOS 1980 limitation.]

Interesting. When you say the date will go to 2073, do you mean what you entered in setup is changed right there in setup, on the spot? If so, this must be considered a BIOS bug. Setup should accept any date at all according to the (current) BIOS specification, and 1473 should be perfectly acceptable (for example).

If you have flashed in a "compliant" BIOS, I'm even more fascinated. A "compliant" BIOS should notice a century change either during POST or when an application (or the OS) requests the date. A century change is defined as the year byte in the RTC transitioning from 99 to 00. If "date knowledge" was programmed into the BIOS to force a date window from 1980 to 2079, this must be considered a well- intentioned (and harmless) ERROR.

The "start date" of 1980 was selected by Microsoft. DOS doesn't keep time like the RTC does, it keeps time as a big count field, which it sets to an initial value during sysinit (the OS boot, not the BIOS POST) with a single BIOS call. Since a big count field has a starting value (zero) and is not a signed number, the date cannot be negative. It must start somewhere. (As a footnote, UNIX does this too, but starts at 1970).

Anyway, if the date is before 1980, this would require a negative number so it's disallowed, and DOS will ask for a valid date, rejecting anything before 1980. The reason it's an error for the BIOS to try to match the DOS window, is that this would violate the UNIX window, which WILL accept a year of 1973. The BIOS is supposed to be completely independent of the operating system.

-- Flint (flintc@mindspring.com), January 09, 2000.

Flint...Thanks for this information, I know it took some time. Here is my response to a couple of issues you had.

Interesting. When you say the date will go to 2073, do you mean what you entered in setup is changed right there in setup, on the spot? If so, this must be considered a BIOS bug. Setup should accept any date at all according to the (current) BIOS specification, and 1473 should be perfectly acceptable (for example).

[The date entered in the setup file is accepted as 1973. On the Digital 450 (BIOS was not flashed) when re-booting the computer shows fatal error. On the Digital 475 (Bios Flashed 4-17-97) the date is accepted in set-up and upon re-boot shows a date at the DOS prompt of 01-09-2073]

If you have flashed in a "compliant" BIOS, I'm even more fascinated. A "compliant" BIOS should notice a century change either during POST or when an application (or the OS) requests the date. A century change is defined as the year byte in the RTC transitioning from 99 to 00. If "date knowledge" was programmed into the BIOS to force a date window from 1980 to 2079, this must be considered a well- intentioned (and harmless) [What then defines a non-compliant BIOS, if a date in the BIOS plays no part of the OS or boot function. Part of the statements from manufacturers (software) claim that some errors may occur when an application date function is not compatable with the system BIOS?]

-- PMD (greenem31@aol.com), January 09, 2000.

[The date entered in the setup file is accepted as 1973. On the Digital 450 (BIOS was not flashed) when re-booting the computer shows fatal error. On the Digital 475 (Bios Flashed 4-17-97) the date is accepted in set-up and upon re-boot shows a date at the DOS prompt of 01-09-2073]

The pre-flash BIOS had a bug. I'd have to examine the code to know exactly what that bug might be. Was there any error message to provide a clue, or just the meaningless "fatal error"?

As for the DOS, I didn't write DOS and can only speculate. It's possible that DOS ignores the century, and treats any year below 80 as being after 2000. But this might be DOS version dependent. Older DOS versions just reported an invalid date.

[What then defines a non-compliant BIOS, if a date in the BIOS plays no part of the OS or boot function. Part of the statements from manufacturers (software) claim that some errors may occur when an application date function is not compatable with the system BIOS?]

I don't know exactly what they are referring to. A noncompliant BIOS typically has a 19 hardwired as the century, with no logic to change it to 20 when the year goes from 99 to 00. However, when the computer is running at rollover, the BIOS can't change the century byte on the instant because the BIOS does not control the CPU. So a compliant BIOS changes the century to 20 the first time after rollover that an application asks the BIOS for the date directly (without asking the OS instead). If the BIOS fails to do this (noncompliant), then the application will get back a date of 1900. Perhaps this is the problem being referred to here.

-- Flint (flintc@mindspring.com), January 09, 2000.

Flint thanks for the time it took to answer all my questions.

-- PMD (greenem31@aol.com), January 09, 2000.

Flint, PMD, et al., good stuff, this is a thread that makes me proud to part of the Great Debate.

One great point was Flint's info on the possible BIOS bug. Now, here we have the clearest example of how we can make a wrong conclusion based upon Garbage In. If we see a bug and conclude it's normal behavior, well, then we can easily make further conclusions about results (eg., widespread failure or catastrophic failure) that simply are not true. This is a most subtle point. I know of no way to avoid making **some** conclusions **somewhere**, especially where life may be on the line. It's just extrememly tricky to make sure we are looking at data and not garbage.

I'm most curious to see how things fall over the next month. I think we will see some serious problems, scattered, not reaching empidemic proportions (like this flu).

BTW, the Boeing 747 problem on the flight line is being reported as a 00 problem. I suppose embeddeds may have had something to do with that. It's a good example of a system that made it through testing and rollover but died (luckily before takeoff, not after) on the 8th of the month. Weird stuff. I'm scratching my head. I'll stick to PeeCee software, thank you.

-- paul leblanc (bronyaur@gis.net), January 09, 2000.

Flint , PMB .... Thanks for the enlightenment ; not that I understood it all . Must agree with others , that the data , speculation , etc. (pre rollover) all seemed to point to serious problems from system collapse . I made an educated guess , as any former science teacher might do , and decided to prep . Now my thoughts turn to this possibility ; if we could be so wrong before rollover ( BOTH sides ) , can we now feel safe in assuming there will be no GREAT suprises in the near future ? ONCE BURNED; TWICE SHY ! Good adage to remember , before making/taking future bets ! Insurance (preps) should not be canceled on wims/'now we know the answer'/ etc. , if 71 years here have taught me anything . Eagle ( Flint: sorry for the flame .)

-- Hal Walker (e999eagle@freewwweb.com), January 09, 2000.

Someone@somewhere.com writes... We told everyone we could find that there would be no problems with power on Jan 1. We told everyone we were Y2K ready. ... What disturbs me is that some people either never listened to us or assumed we were lying.

PMD writes.... If I admit to a Y2K issue, after 30-60 days I can be sued for a multitude of reasons (wrongful death, FDA violations etc. etc. etc..) Because my insurance company doesn't cover Y2K related problems... I go bankrupt. If I don't admit to Y2K problems my insurance company pays under normal liability coverage.... and they go bankrupt. That's a big diff. to me...

ME.. Is it any wonder that people didn't listen? Here is So. California, we also had a power disruption at 7AM on Jan. 3. Lights blinked on and off several time, UPS beeped, clocks had to be reset. This tells me there was a problem with SoCal Edison or their suppliers. Of course it didn't make the news.

Another poster questioned medical equipment. I have an implanted medication pump, computerized, and had no problems. My computer controlled wheelchair had no problems. My grandmother's pace maker is zapping away. BUT a friend had both hearing aids go dead at rollover... go figure!

-- Cyndi Crowder (cyncrowder@aol.com), January 12, 2000.