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.

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 an interface, 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. That is the only reason that explains why there were no serious failurs. I can not accept all those "consultants" feeding their assesments of the equipment they were investigating did not know this and therefore feel that for them TS about to HTF in court.

I'll eat my crow gracefully if I'm wrong - I expect no less from others if they are wrong and judge people's professionalism by the grace with which they accept they have made a mistake or that it seems very likely they are incorrect which is why I'm putting them on the hot seat. We are all on the hot seat right now with our friends etc. so why should RC and others not be also put on the hot seat by being called upon to demonstrate a little more evidence to support their predictions.

I have separated my comments about what we have seen so far into 2 issues the embeds and the business/IT/database systems. WRT to the latter see Yes embeds are "non-issue" BUT IT will have its real rollover TONIGHT here's why where I gave my opinion on these. In summary I agree these systems have time to still play out for the reasons I give in that link and I fully expect there to be siginficant problems with them if there are enough date calculations in the code. Howeever, if we will hear about any problems is another issue.

RC, you may still be absolutely correct about oil, but I have two questions before I can take your arguments as being reasonable:

1) Could you explain to me what critical processes on an oil rig/refinery operate based on it being a certain date vs a certain time interval having passed?

2) On all these sealed boxes with boards you talk about how many have an interface or keypad that lets you set the date on the boards?

RC, I read your reports and your latest assesment and every one of your arguments was made for utilities (end-to-end testing, lack of work done, lack of testing, etc.), all of which turned out to be false. I think largely because of my basic premise at the top of this thread. So again, the answers to the two questions are crucial for you to have a case.

My purpose for this challange to RC is simple:

WRT to the embeds, as I state my opinion is that 99+% of these systems do not use dates, they count time. Those that use dates are still in play and can fail - hence the challange to RC to bring us some fundemental source information from which we can begin to move from speculation based on third party opinion to educated guesses we can make for ourselves.

Given all the dire predictions particulary by Mr. CEO, who was reputed as being in the know, we can say they are either very naive about understanding what was being told to them by his engineers or he knew otherwise. Given the amount of embeds that were in play during rollover in all the systems that were live around the world, we don't need to give the embeds time. I think statistically we have proven the predictions were off base. My opinion about why is that those doing the testing had to know this was the case, otherwise they are incompetant. I mean if you test something for date functionality and there is no way to set the current date, I think you can assume there are no dates calculations happening inside. Those embeds with dates, as I say are still in play.

RC says the oil rigs fail 31 days after rollover, that suggests they have dates so all I ask is to give some examples of what those systems are, why they are critical, and why is their operation based on the date rather than a duration of elapsed time, as *must* be the case in the billions of other embeds that didn't fail during rollover.

You can dismiss my current analysis as Monday morning quaterbacking and in response I say professionals will always evaluate past performence on a project, analyse it and then use the results to improve future performence. That is simply how execellence is achieved. Those of you who have never been through such an exercise in your companies now know the key secret to the successful.

My current thinking is essentailly a postmortem on what happend and to correct the original procedure we all used (i.e. relying on third party opionions) to assess the situation, as it was obviously flawed, to a better more reliable procedure (i.e. have those in the know answer some fundemental questions that would lend credibility to their opinion) so we can all have better assesments.

As they say:

Those that fail to learn from history are doomed to repeat it and those who stick their head in the sand get kicked in the rear. Put them both together and you get kicked repeatedly.

Do we wish to repeat very poor performance in assessing the situation again? I'd like to try and not do that in 31 days. I'm focusing on RC because he's got the main emebed prediciton that is yet to play out according to him. I'd like him to provide some info that would let us all say, "Yes RC has a very good ponit" or "RC's case has problems with it and here they are, would you care to clarify some more RC".

So in a nutshell:

Fool me once shame on you. Fool me twice shame on me.

I don't intend to be fooled twice if I can help it.

Notwistanding my cold hard line now, I am very greatful for those such as RC, Mr. CEO and so forth that provided the information they did. I do not appologize nor regret preparing for a level 7-10 event based on the information they provided. I could not have made the above assesment beforehand as it was obviously impossible to have the opportunity to see all the equipment and test it first hand and had they been correct I was prepared. Its called insurance and I have no problem with paying the price for insurance. As Ed so eloquantly states often, its the stakes that matter.

I can make my above assessment on embeds now since we can see there were no real failures and since RC still has predictions in play, I'd like to take a more hard nosed approach to assessing the quality of his predictions. No professional should ever be offended by such an approach or "cross examination" from others as only two things can happen: He will be proven right or he will be proven wrong. Either way a professional who seeks the truth and not ego will accept gracefully if is proven wrong in such peer reviews that are common place in the scientific community but sadly lacking in the Y2K industry.

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

Answers

I really like this post Interested Spectator. I have also read with great interest RC's previous reports/posts. I have made preps accordingly. I await response from RC. Thank you both for your thoughtful consideration of the problems/risks, etc...

-- Patrick (pmwalshjmj@rocketmail.com), January 03, 2000.

Well IS this is what Russ Kelly has to say about one of your posts,

This is nothing new. that is the way many embedded chips function, for example all of the embedded chips that we know of in the automotive field. That is why not a single car or truck failure was predicted. Other applications require specific dates, such as user specification of something happening at some specific date and time in the future such as security systems (holidays and week-ends are important to know), automated water sprinkler systems, fax machines, VCRs, etc etc etc. Whether chips use specific dates or elapsed time depends on the function. It looks like the writer of the post has "discovered" something that all of the experts have known all along. He ought to do his research better. However, we will have lots of "experts" jumping into the fray now to suggest all sorts of Monday after brilliance. Lets have all the results in first. If any of us have been wrong in a big way, you'll be seeing lots of admission of this. I've suggested as much at my website. Look for clues from Yourdon, myself, Yardeni as indicative as to whether we've misgauged the problem or not. Stay tuned. We certainly are. Thanks for sending this along. Regards, ______________________ Russ Kelly E-mail: Russ@russkelly.com Y2K Recovery, Resources & Research Visit us at http://www.russkelly.com

-- Andy (2000EOD@prodigy.net), January 03, 2000.

"Any thing that is in hardware that deals in time is going to use counters to determine when time has elapsed."

That is an overly broad, sweeping generalization based entirely on assumption.

The only way to determine whether a device uses a counter or an RTC to calculate ET is to examine the specific device *and* its firmware.

Anything else is just guessing.

-- Ron Schwarz (rs@clubvb.com.delete.this), January 03, 2000.

Latest Analysis: Predicted risk for North AmericaLittle risk & getting better!

Sunday, January 2, 9 PM: I am being asked by media and public alike, what is this about? Were you really that wrong? Why has everything gone so well when there were such dire predictions? My response runs along the lines of the following....

Several things caught us by surprise, but massive infrastructure failures was not among them. Many of us have long said that some things are exceedingly safe--electric power and banking for example. No, we've not seen events that go "KABOOM" in the night. Although we did see some failures in nuclear power plants, mainly in Japan but also in the U.S. Human behavior surprised us. We expected more computer virus attacks, and perhaps we yet will as we all go back to work. Some of us expected less civility especially in the larger cities. Human behavior has to this point been unashamedly admirable. And terrorism did not materialize. Yet, and hopefully not at all.

We should remember a few lessons learned from the past. First, it is early in the transition. Perhaps there were too many expectations of huge breakages and dramatic failures at the stroke of midnight. Like a nuclear meltdown or something. We're seeing failures being reported, but of the mundane type that don't get press attention. We also should remember that every company of size had a large staff on duty during the rollover. Their job--to watch and test and make sure things went right. And when they did not, to switch to backup methods and perhaps manual controls. This has been an unprecedented watch over the behavior of technology. Perhaps if technology was always so watched and small failures responded to so quickly, then just perhaps we'd never see those big failures that seems to get all of the attention and coverage. And of course most of our large plants and facilities were closed for normal operations--many ran strictly for the purposes of being watched over. Business resumption begins on Monday for much of the world and on Tuesday for the rest. Systems to this point have not been stress tested. Aviation for example has had few planes in a large sky. The risk of them running into each other under these conditions is exceedingly small according to the "big sky" theory. Aviation may not be stress tested until mid- January.

This much I believe is certain. The first ten days will see a large number of failures. Many will go unreported as they may be uninteresting for media attention, or perhaps simply fixed before anyone knows about it. But others will not escape notice so easily because of the damages they will cause. I also believe that since the infrastructure held together so well, we have the resources to deal with the smaller failures as they happen. For that reason, I am confident that Y2K will not have any significant worldwide negative economic impact. Certainly not a global recession or depression.

I'm convinced we're waiting for the first shoe to drop. And it will be within 30 days, and most likely within the first 10 days. There may even be a second shoe and perhaps a third. Let's not be prematurely euphoric, for much yet remains to be done. The laws of Murphy and of science are against us escaping the transition as smoothly as events to this point seem to suggest. Don't close your command centers yet!

-- Andy (2000EOD@prodigy.net), January 03, 2000.

I've just read Yardeni's admission he will conceed he was wrong if nothing happens by the end of January, and I read between the lines that so far he dosen't really feel anything will happen.

Now here's a professional. He publicaly admits he makes mistakes. When you admit you are wrong you are in a position to now make corrections. Not one second before. That's how he'll improve and do a better job next time. That's what professionals seek to do. Not make execuses.

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

Sorry that analysis above was the latest from Russ Kelly...

-- Andy (2000EOD@prodigy.net), January 03, 2000.

Ron:

The comment you quote of mine as being speculation is not. It is based on the fact that of the billions of chips in play during rollover the percentage that failed is statistically insignificant compared to the number that were predicted to fail. The only explaination for all those that didn't fail is my hypothesis. Of course it can not be 100% true as some do use dates may or may not have failed, that is why I state .001% are probably in that cateogry.

Andy:

If those in the know (read the consultants hired by the companies to do assesment and remediation) knew this fact before hand, then why were they all feeding a line to the public and government (via their reports to their bosses, their CEOs, who then fed the info to government etc. etc.). Futheremore they then must have known there would be no significant failures, so why did the government waste so much time preparing for them. Because simply the government had false information. As I said it is *not* possible that the equipment assosors did not know what I state above with respect to embeds. And your quote confirms my hypothesis that it seems to have been common knowledge amongst those in the know.

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

Now here's a professional. He publicaly admits he makes mistakes. When you admit you are wrong you are in a position to now make corrections. Not one second before. That's how he'll improve and do a better job next time. That's what professionals seek to do. Not make execuses.

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

======================================================================

Not to belabour this point IS but you've given this particular speech a few times.

You seem to be acting as if you feel somehow ***cheated*** by these fine folks.

they went out on a limb with their best guesses based on data available - data I might add not half as comprehensive as the Navy and CIA who made identical predictions.

Give it

TIME

-- Andy (2000EOD@prodigy.net), January 03, 2000.

IS

we cross posted - my question to you is what are you getting at?

do you sense some sort of conspiracy here because that is what is coming across in your posts - if so, that's fine by me, I'm quite willing to explore that avenue.

-- Andy (2000EOD@prodigy.net), January 03, 2000.

Andy:

I already stated the reasons why I made this post (and they state clearly I thank all for the predictions and assesemnts) and that is I'd like RC to provide a bit of info so all of us can make better predictions. Do you *not* want to make better predictions?

Why waste so much time arguing my post? Why not let RC just answer the two questions? Are you afraid of the answers?

WRT to CIA and NAVY all info came from the same sources: the utility company CEOs who got their info from their Y2K team leader who got their info from their own engineers and crews like Mr. CEO sent out to assess the situation. The root of the problem is at the bottom of the info food chain, and those down there will have a lot of explaining to do about why the info they provided resulted in those hire up making such extensive preparations when those at the bottom, the experts as you quote Russ Kelly calls them, knew otherwise.

-- Interested Spectator (is@the_ring.side), January 03, 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.

Someone:

Thank you. But I have one question for you based on your answer. You say:

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.

Why didn't you just look for a way to set the *current* date on the chip - i.e. an interface, keyboard or keypad pannel? If there is none then I can almost assure you with 99.99999999% confidence that the chip or board does not use dates. Seems to be a very simple fool proof way to quickly find out how the chip calculates time. (If there was no documentation how did you know what to test and how did you know how to send inputs to the chip to test it? For ex: how did you also set the date as 1/1/2000 for testing?

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