Please go easy on me if this is a really stupid question.

Question for anyone who REALLY knows the answer:

If some embeddeds have a RTC in them, and don't look to an outside source for the date, would their current date be off by the amount of time lapsed between manufacture and installation? (With the thought that once installed, the chip has a power supply to begin "ticking"

This assumes that the RTC start date=manufacture date.

And what is the typical lag between manufacture and installation date? Amonth or more?

If this is the case, will embeddeds then be more susceptible as we go through January into February?

-- Duke1983 (Duke1983@aol.com), January 05, 2000

Answers

A follow-up:

If a power supply to the RTC, or chip, is interrupted, will the date reset to the start date (whatever that might be e.g., manufacture or some accepted convention).

My Mac at home seems to have reverted to a default date when the internal power source went out....Files got stamped with a date in the 50's.

-- Duke1983 (Duke1983@aol.com), January 05, 2000.

Duke, if it is a dumb question, you've got company, because the same thought occurred to me yesterday.

-- Dzog (dzog@plasticine.com), January 05, 2000.

Duke, I'm in the middle of some late chores, and am not a programmer, only a lowly pc user. But your question sounded familiar. Please take a look at Mark A. Frautschi's authoritative paper - the section I remembered in Paragraph no. 5 in the "Discussions" section. Had you seen this before? It is probably so basic, I'm sure all the utility experts (Rick Cowles, Roleigh Martin) are VERY aware of it, as are a number of professional programmers who post here.

But I would be interested in your comments, which I'll read later. And in any input from anyone as to whether this can still affect infrastructure, particular electrical power.

Thank you all.

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

Sorry:

http://www.tmn.com/~frautsch/y2k2.html

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

Duke:

Here is what the reality of the matter is with embeds and date and time. (I posted my analysis in the following thread.) Exerpts follow.

Why nothing was ever going to happen with the embeds

----- EXERPTS FROM ABOVE THREAD FOLLOW -----

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.

----- 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 05, 2000.

this is a great point. this is exactly where the problem will reside. these smaller glitches are only representative of the short cuts techies have made in the software development. and may prove to be disasterous in coming days but the reason there is even the existance of "software developement" AT ALL, lies on the foundations of these embedded chips. this is why i think japan will see these failures quicker than we do. because a box of chips could set on an american bench non-powered for months. but thats not as likely to have happened in japan in 1970 :) little buggars...

we can expect embedded chip failures this year. and further, i predict that someone will come up with a way to determine the life left on replaceable chips. making lots of money. becuase the "chips will have to be re-invented, and that leads to many generations of design. but its not impossible, and could already be in the works. or even finished. but who gets the good stuff. i wonder.

-- Nathan (Nathan@ciaosystems.com), January 05, 2000.

I'm wondering, though, why wouldn't any of the 'alarmists' be currently addressing this issue, if it does have validity?

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

Jim:

I'm an alarmist and I did address the issue. See my reply above.

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

Jim, thanks for the link. I had never seen this paper. I've read the paragraph you cited, it looks like it is right on point with my question.

What is this guy's background?

Interested Spectator, thanks for your reply as well. I saw your thread yesterday. It seems that you may be right also. That is that most chips don't have a built in RTC. The big question, then, I suppose, is what is the true percentage? 99.999% is too high, my gut tells me.

If the paragraph 5 of the link Jim provided is correct, then I would say we aren't out of the woods yet. IS, maybe you could read that paper, and tell us what you think.

OTH, if a chip fails in this manner, can't we simply remove it (thereby isolating it from its power source), and re-insert it as this will prolong the life by resetting the RTC to the "epoch" date. That's assuming, of course you know which chip it is.

Interesting hypothesis also, Jim, that you put forward: That Japan will experience the failures before we in the U.S. If true, it would give the U.S. an early warning, if you will, and perhaps allow us to "reset" the little guys to the epoch date by removing and reinserting wherever possible.

-- Duke1983 (Duke1983@aol.com), January 06, 2000.

Duke and Jim:

I read the report 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 existed there.

Now with respect to IT/business systems/dates, that is a whole different issue (as the article also points out) because here we don't track elapsed time, but store dates permenantly in databases. The program will blow up any time they use the dates if they are not y2k compliant dates and programs.

For when these errors occur see my post from 1.1.2000

Yes embeds are "non-issue" BUT IT will have its real rollover test TONIGHT here's why

I was a little surprised not much happend during the night of 1.1.2000, but I think a lot will on 1.31.2000 when the overnight batch runs take place.

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

http://hv.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=001A1t

SNIP

We are discussing Y2K year anomolies correct? It is my understanding that no CPU chip contains a clock. RTC to be precise. Yes the ROM/PROM/EEPROM etc can have date calculating programming. But as I said above, that kind of programming is bulky and takes up a lot of programmable space on the chip. Also the programmable chip needs a unfailing timing input to keep the date and time. This is where a RTC and BIOS comes in as the easiest and most common source (if not the only source). The programmable device would be doing the "job" of the BIOS and it would be redundant to have it do so. t s so much easier to grab the date data from the BIOS. To provide accurate date-time you need a source that would keep "time" in a reliable way otherwise the function would be moot. That means the "black box would also have to contain a RTC, BIOS and a Battery, as well as an external source of power. The black box if totally independant of an external computer would have to had the time and date set upon initialization. In my research with semiconductor manufacturers, I have found that they do not do this at the factory for many logical reasons. As it is common practice for maintenance manuals as well as setup proceedures to come with such devices, the information would be available to those who are assigned the responsibility to connect and maintain the device. They would be aware of the need to periodically check the voltage on the battery. They would be aware that the Bios or its counterpart would have to be checked and updated to Y2K compliancy. The documentation would state the fact of the existnce of RTC and Bios and how to set the date.

-- Cherri (sams@brigadoon.com), July 30, 1999.

BIG SNIP

OK Cherri,

I guess we agree on what an "embedded system is? I'm no ES expert, but I have been playing with all kinds of DIGITAL computers for the past 3 decades or so, esp.with ASSEMBLY language. So, I guess I've got a few more "minor" points:

"The main reason for this is that it takes up a lot of memory to write the booleen algebraic equations for seconds up to years, leaving little room left to program the chip for the desired function you attempting to accomplish."

Come on now Cherri, what does it take to "count and compare?"

Let's make it easy, and assume that we have a "clock" that generates an interrupt every second. Do you think the following (x86) code would work, to update seconds, then minutes?:

WAIT: NOP ; wait for interrupt

INC SECONDS

CMP SECONDS,59

JL WAIT

MOV SECONDS,0

INC MINUTES

CMP MINUTES,59

JL WAIT

; DO THE SAME FOR HOURS, DAYS, MONTH AND YEARS!!!!!

This only generates a few bytes of program code, next to nothing, hardly a dent in the space available on the ROM. Next point:

"To provide accurate date-time you need a source that would keep "time" in a reliable way otherwise the function would be moot. That means the "black box would also have to contain a RTC, BIOS and a Battery, as well as an external source of power."

First, we don't need a RTC since the above code EMULATES a RTC.

Second, the BIOS is OUR PROGRAM that is contained in the ROM. We are the BIOS.

Now, lets talk about the battery, and the external power. I'm in a bit of a rush, and don't have time to locate the link in the archive. We had a post about a SOLAR POWERED WATCH, that was placed in a dark drawer for 30 days, and it kept perfect time. It had NO BATTERY. but a CAPACITOR was charged by the TINY solor array, that kept the watch powered in the dark. Yes, a capacitor is just like a battery, it stores juice. A capacitor is a very common component, maybe more common than a "chip."

So what do we have in the "guts" of the watch? A very tiny DIGITAL circuit, that takes a TINY amount of power to keep it running, and it is VERY accurate. Do any "embedded systems" use such a clock? I don't know, I'm not the expert. I sure can't think of a reason why not. Next point:

"The black box if totally independant of an external computer would have to had the time and date set upon initialization. In my research with semiconductor manufacturers, I have found that they do not do this at the factory for many logical reasons."

Another, less common component is NON-VOLATILE RAM. This is a special kind of RAM that remembers it's contents when power is lost (maybe we can't keep the watch in the drawer for 60 days...). When power is restored, it picks up where it left off. This is important when "sequencing of transactions" is important. Do any "embedded systems" use NV-RAM? Somebody sure does, but I'm no expert..

This is what our old friend, BRUCE BEACH is about. Is he an "expert?"

Any comments, Cherri? <)=

-- Sysman (y2kboard@yahoo.com), July 30, 1999.

SNIP

Maybe one of our other "pollys" would like to discuss this. Flint, you're a "chip" guy? Hoff maybe, or are you stuck on "aviation?" Doomers@suck.com?

Come on folks, this is the start of my reply to BRUCE BEACH. Am I nuts? Is Mr. Beach nuts? Is Cherri nuts?

Or is it all hype??? <:)=

-- Sysman (y2kboard@yahoo.com), August 01, 1999.

SNIP

Sysman:

OK, I'll do my best. I've written a lot of this before, you know.

(1) Your example is correct, it's quite possible to keep track of time without some RTC function. Indeed, most low-level embedded programs do just that for a variety of purposes. Far fewer of them keep track of real, calendar time (synchronized to the outside world) since there is rarely any need to do this. Those that do generally require some method of resynching, since those crystals aren't all *that* accurate. An RTC itself passes muster if it gains or loses less than about 2 minutes a day. But that's a day off every 2 years, so some outside update function is required if the time needs to be synched with real time. And if such a sync function isn't required, then it isn't real time after all, it's just a timer.

(2) Your example is fine, I've done this myself. But you will notice that there is no y2k error in it! Typically, to introduce such an error your code must store time values as binary coded decimal (why?), then allocate a single byte for each field (normal enough), then initialize all these values to real time (implying some method of setting the time, required as discussed above), then ignore overflow of the year byte, then create code that assumes that such overflow can't happen! Finally, when overflow does happen and is mishandled, the device needs to misbehave in some way that seriously compromises the application it's used in.

Now a couple of observations here. To find embedded systems where all of these things are true, you must eliminate all but a very small handful of systems. Very small.

The vast majority of embedded systems don't keep track of real, calendar time at all, since there's no reason to. They use simple timers.

Of those systems that *do* something with the date, as opposed to just keeping track of it, this functionality is rarely burned into the microcontroller or other ROM space. That would be the wrong logical level in almost all remaining cases (which was a small total number to begin with). This is NOT to say that improper function due to date mishandling isn't part of the "system", it just happens at a higher level.

(3) Most of the misunderstanding about the dangers posed by embedded systems are based on one or two sources of confusion. First, people tend to equate what is *possible* (as in your example) with what is actually *done*. This is a simple error to make. As I said, it's a rare system that keeps track of calendar time at all.

Second, there is a real problem defining an "embedded system" at all. These tend to be layered as used in sensitive applications (I'm not talking about your VCR here). As an example, think of an ABS braking "system". Each wheel has a wheel control "system" (consisting of sensors, servo mechanisms, a microcontroller, etc.) That's an embedded "system". Now, each wheel system reports to a vehicle-level braking system that 'knows' about each wheel. At this level, we find logic to prevent swerving due to differential friction coefficients at different wheels.

This system in turn reports to a subsystem that, for example, handles wheel control generally -- braking, differential, alignment, whatever. Finally, this subsystem reports to a master system that handles all aspects of the vehicle. And perhaps you could throw in the diagnostic system used by the mechanic to query and update each vehicle's system.

The purpose of this example is to emphasize that in most important cases, there really isn't any good place to draw a line and say, *this* embedded system is everything within *this* circle. As the circle becomes larger, of course the number of actual chips within it grows. At the chip level, y2k bugs are vanishingly rare. At the highest levels (the "assembly line system", for example), you are talking not only about millions of chips, but about networks of servers running custom applications handling thousands of tasks being performed by tens of thousands of pieces of machinery.

At this "highest" level, it's not at all surprising to find 30-40% of "systems" have y2k issues. But people confuse the incidence of issues at this level with the incidence at lower levels, so I've seen people claiming that 30-40% of "embedded chips" have y2k errors, and there are 50 billion chips! This is a logical and semantic problem, NOT an accurate assessment of what we're facing.

As a footnote, there was a thread not long ago asking me to respond to Cory's challenge. In that thread, I spent some time explaining why embedded errors are less "contagious" than IT errors. I won't repeat that here, but it's another aspect of this same issue.

-- Flint (flintc@mindspring.com), August 01, 1999.

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

Thank you all very much for your contributions to this thread. I am learning alot as we go.

Would it be fair to make this statement:

There is widespread disagreement as to the definition, character, functionality and approach to what an ES is, and how it is manufactured. It would appear that there are numerous approaches, Some of which may result in Y2K problems not necessarily on 1/1/00, but rather at some later date.

The pivotal question becomes what is the percentage breakdown of types of embedded systems, and have the approaches changed or evolved through the years such that ES's from a particular time period may be more susceptible than other periods?

The current threads relating problems in credit cards, air traffic controll, pension payments, etc. may, over time, be able to give us a better picture of this.

Let's keep our eyes open!

-- Duke1983 (Duke1983@aol.com), January 06, 2000.

Cherri:

I found the post confusing with so many quotes of quotes, so I'm not sure what side of the issue you are on (my side or opposed to my side -- I think you are with me on this). However I have given my responses to some of the issues raised so you have my perspective.

I've coded my share of assembler. Firstly most embbeded systems do not use full blown CPUs, they'll just have a clock generate interrupts and they'll use a few chips to count them up and do comparisons on them.

All that the assembler program provided does is count interrupts comming every second and keep track of them in minutes and seconds.

Why don't you hold a date/time value (yy/mm/dd:hh:mm:ss:hhh) in assembler and keep track of an interrupt ticking at hundreaths of second to begn with. Then use these date/time values to store important times and compare them to other date/time values that cross the year threshold to see if one date/time is less then, greater than or equal to a second date/time. Or try adding/subtracting a certain number of seconds to a date time value that crosses the year threshold? Now recode the same thing using a simple counter (see the *huge* difference). Now start using these two functions a few dozen times and look at all the parameter passing (pushing and popping values off the stack) etc. you've got to code up and debug. Also look at all the code when you need to store the date/time values, initialize them etc. Also look at the size of the data items themselves.

Remember a lot of these were created when memory was an issue. Now think about the costs involved in doing the simple timing job more complexely using fullblown CPU circuitry and support chips rather than a few simple logic chips to handle the application. I'm not saying all applications are this way, I'm saying .001% or thereabouts use date/time values right in the embeds for their calculations. And this is based on the fact there were so few failures. Even the report I was referring to suggested that .05% would be needed to fail to cause chaos. We don't have chaos, so less that that failed.

Now, we know that very little serious embed replcacement work really took place, so that means what worked didn't work because it was fixed, it worked because the assumption of the number of non-compliant chips was incorrect. I submit it was because less store and calculate date/time values using human readable representations right on the chip so there were less chips to fail to begin with.

FYI a simple double word (4 byte) counter for seconds will go for 49,710.27 years. I think longer than most people need to care about. An simple 6 byte counter will count hundreaths of a second for 89.253.77 years.

With respect to the power issue. Mission critical apps will not leave the reliability of their timing functions to a capicator. They require a solid power source - battery or AC converted to DC. I have never seen an maintenance manual say "plese do not leave disconnected for more than xxx mins/hours/days".

Your example of a solar watch is unique because the designer of the solar watch to work has to assume that it will be in the dark sometimes and in order for the user to be satisfied it had better keep time when it is dark. You are transplanting technology from a specific application and saying "see it has been done here, therefore it has been done everyhwere." Very faulty logic.

I submit to you that no designer of a real-world embed system (i.e. one that controls critical functions that affect lives) has made their design assuming that the system can function satisfactorily without power, unless the fact that there may not be power is a common occurance for that application and it assumed that an external battery (button battery for just the clocks or a full blown UPS for the entire system) to provide that power is not going to be avialable (that is why your "solar" watch is unique). That is why all these systems need a way to set the date if it is incorrect to begin with. Either through an interface, keyboard or keypad. Most embeds have none of these. They are black boxes. Those that aren't have these and like I said keep track of time with counters for all the reasons I gave.

WRT to Non-volatile RAM, all these do is keep the values in memory from being lost. They do not address the issue that without power the clock is not ticking and the ticks are not being counted. The momeent the power goes, all the non-volatile RAM does is keep the last value. That is of little help when you are trying to track time. Its sort of like going into suspended animation for an unknown period. You need power.

Cherri, you are quoting Flint from Aug 99 who is quoting guesses that upto 40% of the chips have a y2k problem. Our issue here is not to convince each other if there will be or will not be a y2k issue. That is moot, we have the answer, and therefore the guesses we now know were wrong.

Our task here is to try and find out why probably less than .001% of the chips failed, regardless of the application, regardless of the age of the technology (3rd world or 1st world), regardless , regardless regardless. Given the overwhelming failure of embeds to fail, I submit there will not be a variety of answers (although there will be within the .001% part) but there was a fundemental missunderstanding of the problem to begin with. Otherwise statistically we would have seen more failures, or a concentration of failures somewhere (i.e. in certain applications, or certain era of equipment, etc.)

-- Intersted Spectator (is@the_ring.side), January 06, 2000.

Interested Spectator:

You wrote:

"Cherri, you are quoting Flint from Aug 99 who is quoting guesses that upto 40% of the chips have a y2k problem."

Not so. Cherri quoted me quoting *empirical observations* that up to 40% of Large Scale Embedded *Systems* had y2k issues (most of which were cosmetic). My entire point was that system-level error rates of the largest systems were being confused with chip-level error rates, and I'd just spent a very long post explaining why chip-level rates were insignificant in practice.

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

Flint:

Just trying to understand your position (which I think I understand to be the same as mine, if I am reading you correctly). Am I therefore correct that your position is that:

Chip level issues are insiginficant, ergo no real y2k issue here.

System level issues are cosmetic, ergo no real y2k issue here

Therefore no real y2k issue with embeds and that's why we didn't see any signficant failures.

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

Flint:

Forgot to add at the begining of last post, (reply to you) that you are correct, I stand corrected as I misread what she quoted from you.

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

Interested:

Not entirely cosmetic. There were reports of assembly lines stopping at GM and Chrysler when they first turned their clocks ahead to check it out. And I certainly expected more such problems than we've heard about. My guess is the functional problems weren't particularly difficult to work around.

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

Flint:

I agree with that, and I was wondering how you came to the "cosmetic" conclusion my self. But I still stand by my original assessment about why the embeds were largely a non issue. What remains to be seen is what kind of an effect the .001%, which I think have date problems, will have. I think a negligable effect.

BTW I think that unless we see some very clear catastrophic failures that can be clearly attributed to y2k (either due to embeds or business systems), I do not believe that *any* amount of failures will ever vinidate the Doomers because those failures will never be reported nor will their side effects ever be attributed y2k because doing so would mean all the pollies (i.e. press, etc.) who have been knocking themselves over backwards over the past 7 days to prove the doomers wrong will have to eat bulk crow, and they are not going to let that happen, by simply not reporting it. No sense in using your own gun (i.e. the reporter's own media outlet) just shoot yourself in the foot.

So as they say perception is reality and the reality is that doomers are not going to be allowed to be percieved as correct in any way shape or form, ergo they will always be wrong even if they really were right (which we still do not know for sure yet).

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