I know it's pretty ballsy of me to come up with another theory after Hoff shot down my last one, but I don't care.

Ok, I'm an embedded chip. I hit an error condition. I can't just do a core dump like a mainframe. I have to keep going. This is real-time, I must be fault tolerant. I send a message of the error condition to a SCADA system, then I restart the program that I run.

Makes sense, doesn't it?

-- Amy Leone (leoneamy@aol.com), January 01, 2000

Answers

OH, yes. And then I keep counting.

December 31, 1999, and 36 hours.

Etc. Etc.

Until I hit 100 hours.

On Monday.

-- Ariana (pergados@yahoo.com), January 01, 2000.

I'm no programmer, just a dumb pc clerk. But I started researching y2k one year ago, sank our whole small savings into 4th qtr. preps, and this is only my 2nd posting anywhere today, other than one on CNN Yr 2000 Bug.

So...please...what are you two saying? What is the "100 hours" a reference to? I just don't understand. I was not believing there would necessarily be massive outages/breakdowns at rollover. I assumed only 10% problems at rollover, but was planning for the worst. But this is just ridiculous, I feel as if I've entered an alternate reality, where nothing makes sense.

Really, what are you saying? Thanks, my appreciation for any replies.

-- Jim Young (jyoung@famvid.com), January 01, 2000.

Wrong

But they why bother learning how they work when you can just make up something and feel smug about yourself for being so "smart".

-- Cherri (sams@brigadoon.com), January 01, 2000.

Oh brother! I'm reminded of Lucy explaining the facts of life to Linus.

There are lots of ways systems end up being fault tolerant to dates. Far and away the most common is by not using dates at all. Next most common is not using dates in calculations, or to make decisions.

In those rare cases where a decision is made (AND it is made wrong), the code will keep executing, and do *something*. This all depends on the accident of how the code was written. The primary categories of accidents are (1) it does something too early; and (2) it doesn't do something it should, or does it too late. Calculations are followed by comparisons, and there are two code paths: yes and no. One of them is followed.

It's absolutely possible to construct scenarios where these accidents might cause functional problems. Indeed, this has been a favorite pastime on this forum. The resulting impression is that the longer the list of things you can compile that you *might* run into if you fall asleep at the wheel, the more *likely* you are to fall asleep at the wheel! And if you can think of twice as many things you might run into today as you thought of yesterday, then you are twice as likely to fall asleep!

In reality, people rarely fall asleep at the wheel.

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

One more time for the record.....

Most embedded chips (systems) don't give a fiddler's fart about the date.......those that do have some type of external interface so that date on them can be changed.....

This idiocy that there were millions of chips completely inaccessible that would crash was pure bullshit to put it bluntly.......

A chip/system that uses a calendar date MUST have a way to change or set it or else it would be completely useless!

-- Craig (craig@ccinet.ab.ca), January 01, 2000.

Jim Young,

The questions about embeddeds has been answered. They did not crash and there is no way some nonexistant hidden clock with some other (non existant) startup date will make them crash either.

Monday business will see what all of the software fixes have given us. By Friday I believe it is safe to assume the problem was fixed.

-- Cherri (sams@brigadoon.com), January 02, 2000.