Bruce Beach has some impressive credentials and has been very active on the Y2K front lines. Read his very interesting report.

-- lurker (hmm@m.m), April 10, 1999

Answers

Sorry I see a thread was started on this. Didn't recognize it by its title. Straight Info on Refineries thread.

-- lurker (hmm@m.m), April 10, 1999.

Lurker - thanks anyway!

Read this link - and ask yourself the obvious question...

http://www.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=000hUW

-- Andrei-hung-lo (2000EOD@prodigy.net), April 10, 1999.

You guys are just trolling for a fight, right? Can you think about this???? While this may be an amusing sport for you, there are people out there that are trying to make *sense* out of information that is not a part of their field.

*IF* you professionals (and I am using that term loosely) really want to argue so much, can you try to keep it to *human* levels, so that possibly somthing CONSTRUCTIVE can be the result.

What generally ends up happening is, name calling type pissing contests, and if we really need that we can pretty much follow the latest crusades of our military & politicians.

The point is there are people here trying to *understand* things that people generally learn over a period of years in a 'crash course' so to speak.

So... do we believe gov. types that at least appear sane & rational, or do we believe doomers/pollyannas that play out like 'clash of the giant egos'?

I really wish I had faith in my own ability to fully understand the complexities of the systems involved (in such a short period of time), because the arguing adds to the confusion & I can't tell who is more full of crap.

It makes most of those arguing look like pompous B.S.ers.

When some newbie stumbles upon this forum in the middle of that, I really feel for them. Where else on this web can they go?? This was the BEST y2k forum out there. Please don't ruin it. I don't believe it is too late yet for newbies, let's not scare them off.

Where are half the regulars?? Burned out from all this garbage, that's where. Let's stop, before everyone decent is gone. *rant mode off*

-- Deborah (infowars@yahoo.com), April 10, 1999.

Deborah,

I fail to see how "Bruce Beach: The Embedded Processor SECONDARY Clock Problem" is garbage. Maybe you see it that way. I suggested taking a look at the crap issued by the shills in Boston - now THAT is garbage in view of all that is know. Read between the lines Deborah.

Newbies to this forum had better roll up their sleeves and get with the program - time IS running out. The archives are there for a reason - newbies can learn more there than anywhere else on the web.

-- Andy (2000EOD@prodigy.net), April 10, 1999.

Deborah,

When folks lead others to believe they are something other than professed they must be exposed. If not, they will continue to mislead all.

Ray

-- Ray (ray@totacc.com), April 10, 1999.

Andy,

No, I must not have been clear. Bruce Beach: The Embedded Processor SECONDARY Clock Problem" is NOT garbage. It is in my opinion excellent, in fact one of the best things dealing with embedded systems I have seen in a while. I am very thankful to have had an opportunity to read it. I certainly could not have written it, at this time in my life.

What was frustrating me is the FIGHTING. There was a thread started earlier on the Bruce Beach paper -- Straight Info on Refineries. It seemed like there was some disappointment, that this thread hadn't started a juicy fight yet.

I am not a computer 'pro', I have the added burden of trying to understand things many of you take for granted. I am not the only person in this position I might add. I really like you guys & I was careful not to single anyone out. I know I'm a real pain in the behind oftentimes myself. ;-)

-- Deborah (infowars@yahoo.com), April 10, 1999.

Ray,

What? I'm afraid, I don't understand. Could you be more specific?

-- Deborah (infowars@yahoo.com), April 10, 1999.

Good afternoon Deborah.

Yes, I have been guilty of this name calling non-sense. I think it's a natural reaction when someone else starts it first. It is also a waste of everybody's time. I offered a truce with a few of my "enemies" a couple of weeks ago, and it has been for the most part successful. I still get the urge, but think twice about it before I hit the sumbit button.

There is a difference between a "pissing contest" and a valid argument. There are so many sides to this problem, everyone has their own opinion, and no one knows for sure what the result will be. If someone like Norm posts one of his happy-face articles, I go out and try to find and post the other side of the coin, in an effort to bring some balance to the issue.

It really is up to each individual to make up their own mind as to how bad the results of this problem will be. I think the best we can do here is to try to find and present all the evidence that we can, and present it to them. <:)=

-- Sysman (y2kboard@yahoo.com), April 10, 1999.

Sysman:

Hypothetical failure modes, even though possible, are not 'evidence' of failure. A year and more ago, when not much investigation had been done, such speculations were all the 'evidence' we had. These fears were valid until proven otherwise.

Well, time and study have proved them otherwise. The actual results of our efforts are the real evidence. Those like Beach who continue to rant about possibilities now proven rare to nonexistent, aren't helping us understand the reality. Beach needs to find a new schtick. His old one has run out of runway.

-- Flint (flintc@mindspring.com), April 10, 1999.

Did you guys plan that?

-- Deborah (infowars@yahoo.com), April 10, 1999.

Good afternoon Flint.

I think we pretty much came to an agreement on the other thread. When I said "results of this problem" above, I was refering to the whole Y2K problem, not just the emnedded issue.

Deborah, we didn't plan this, we're just both on-line too much! <:)=

-- Sysman (y2kboard@yahoo.com), April 10, 1999.

Deborah-- it's just that "marketplace of ideas" thing in action... kind of a messy way to do business, but there you are.

-- Max Dixon (mcdixon@konnections.com), April 10, 1999.

Sysman,

Well, I have posted things I am not proud of myself (that post being one), I really regret how judgemental the post sounded. I could have found a *kinder* way to express my opinion.

That being said, I agree that there is a difference between a pissing contest & a valid argument. A debate can be valuable. When I started coming to this forum in Jan. there were some debates I learned a great deal from. Lately some of these debates have just seemed counterproductive. I think I need a break, *sigh* I'm getting kinda crabby. ;-)

Peace,

Deborah

Flint,

I have a question about your post. You stated: "These fears were valid until proven otherwise."

Okay, I'm open. Where's the proof?

You also stated: "The actual results of our efforts are the real evidence."

Dude, I'm clueless, where are the results? Help me out here, I want to understand your point.

-- Deborah (infowars@yahoo.com), April 10, 1999.

Deborah:

For one of countless examples, see the post from Dan on the NERC drill thread. He's been there, he's personally done the equipment testing, he was involved in the drill.

All of the testimony we have from those actually performing the tests and remediation of embeddeds agree -- problems were much less frequent than feared, most of the problems found were much less serious than feared, repiar/replacement of noncompliant equipment has been much smoother than feared, order backlogs have been much shorter than feared, the list goes on and on.

I'm quite sure that we won't find everything, and there will be isolated serious glitches. NOT a collapse of power, phone, etc. Those fanning the fear could by now cite a large and growing statistical base of evidence. And they would, if it existed!

-- Flint (flintc@mindspring.com), April 10, 1999.

Flint,

Thanks for your response. That is really weird. I was on my way to ask Dan a question, when I stopped to read this!

Thanks,

-- Deborah (infowars@yahoo.com), April 10, 1999.

Flint:

As I have read them, most of the more recent tests on embedded microprocessors have been done on what Bruce termed the "external clocks". As I had originally understood the issue, these "secondary, internal" clocks that were "burned" or hardwired in were the initial worry. Now, the good news seems to focus on the "external" clocks, essentially in rolling them forward to run in a Year 2000 environment.

Now, this is by no means my area of expertise. I'm a generalist currently working in the employment industry. But, electrical engineers (applicants or candidates of mine) that I've talked to "off the record" have mostly seemed to confirm what Bruce has said.

Are these embedded microprocessors your area of expertise? I have appreciated your "balanced", "devil's advocate" approach before. I'm not trying to start a flaming contest. I had been somewhat willing to accept the developing consensus about this issue, but darn it, I just don't know. So I have to plan "for the worst.

This article makes a clear distinction between setting external clocks forward (apparently rather simple) and setting the internal clocks forward (this seems to be quite difficult to impossible in some cases).

Also, over the months I've been trying to follow this issue, I recall a fairly general earlier consensus that to read or to change the "burned in" code of a microprocessor required a special compiler, I believe it is called, to program the chips, and that these are difficult to impossible to obtain in the case of older microprocessors. All of the sudden, testing is being done by simply "rolling forward" clocks, and no problems are being discovered.

Maybe I'm completely misunderstanding the situation. Maybe we have a case similar to that of Visual Basic or OOP programmers not understanding the quirks of Cobol and other Mainframe programming.

Do we have any firmware engineers out there?

-- Jon Williamson (pssomerville@sprintmail.com), April 10, 1999.

Good evening Jon.

I think the "special compiler" you are thinking about is a ROM/PROM "burner". This is a box with a parallel type port, and a socket for a "blank" ROM. The compiled code, like a .COM file on a PC, is copied to the blank ROM using this device. Most of them also have another socket so you can make a copy of an existing ROM. I've only used them on a small scale, so I don't know what the mass production process is. They are quite common in "engineering" type shops. Most of them can handle a variety of different style ROMS. Hope this helps. <:)=

-- Sysman (y2kboard@yahoo.com), April 10, 1999.

Jon:

You're right. Microcontrollers contain ROM, RAM, interrupt mechanisms, etc. It is possible for the ROM programmed into a microcontroller to access a real time clock (RTC), and to be the only interface to that clock. It is essentially impossible to roll such clocks forward, since the only interface is to read it, and there is no code programmed into the microcontroller to set it. So far, so good.

Now, in this environment 'real time' is necessarily not synchronized with real time as we know it. These clocks aren't very accurate, typically losing or gaining up to 2 minutes a day. Furthermore, the initial time in the RTC is usually undefined at power-up. In other words, we're not looking at actual dates here, we're using the RTC as an interval timer over long intervals.

If there were some necessity for keeping the RTC in such devices synchronized with the real world, then there *must* be a mechanism for resetting the RTC to prevent drift and set initial time. So as a rule, if the time can't be set, the date isn't relevant.

This doesn't mean that a rollover error might not happen some day. I'm guilty of this myself, having written code that will have a 1- time error 25 years after initial power-up, assuming a perfectly accurate clock. But these errors even when they lurk inside the microcontroller ROM, won't all happen anywhere near the same time. But they will probably happen, here and there, mostly between 2010 and 2020. Some may have already happened.

Hope this helps, and isn't too technical.

-- Flint (flintc@mindspring.com), April 10, 1999.

Thanks Flint, that helps. I still have a question about the role of the "external clocks" he mentioned. Does this keep everything in sync, and if so, doesn't this mean that any failures will also happen in sync? This isn't my area, just trying to figure it out! <:)=

-- Sysman (y2kboard@yahoo.com), April 11, 1999.

Sigh. I have made a promise to a friend that I will write a response to the Beach paper. I will do so, but not tonight. I am way too tired and it is late here.

-- Paul Davis (davisp1953@yahoo.com), April 11, 1999.

Thanks Paul. I'll check here and the other thread tomorrow. Sweet dreams, me too! <:)=

-- Sysman (y2kboard@yahoo.com), April 11, 1999.

My reply to Bruce Beach and his essay on The Embedded Processor SECONDARY Clock Problem. First and foremost, he does not use any semblance of standard terminology. This makes the whole thing very hard to read. I am going to talk in the real terms, if this makes anyone drop out, too bad.

His first few paragraphs tell you about him, though if this is the Bruce Beach I know about, his degrees are in economics, not Computer Science. That hardly matters, and if this is another Beach, I apologize. So, let us have a look at what the meat of this actually says.

After we skip over the usual "I know about this and I don't think anyone else does" stuff (WHERE do these people come up with this much EGO?) he starts describing the insides of a microprocessor. OK - rather over simplified but not too bad. In addition, he is quite correct that CPU's do not keep time. Support chips are necessary. To cut to the chase, he is talking about RTC (Real Time Clock) chips. An RTC chip may or may not be used as a dating device; some are just used as interval timers. Depends on the application. Moreover, almost none of them use four digit years. All an RTC does is keep time and date - and it puts this out on the bus that connects it to the CPU. If you want a world of tech info on RTC chips just look on the web - here is Motorola's chip site

http://mot-sps.com/sps/General/chips-nav.html

for an even bigger thrill, do a site search for Real Time Clock.

Therefore, the RTC puts out date and time. That is its sole function. So he asks if the PROGRAMS running on a machine, whether or not they directly access the RTC (doesn't matter if it is a ladder program or not, whether or not it is burnt into a PROM or EPROM or EEPROM, a program is a program), whether or not the RTC even can be set by a program or hardware function, he asks if these programs can fail to act as expected when the clock rolls over.

My answer is - well of course, they could. AND it doesn't matter in the REAL world whether they could or not - and we will get to that in a moment. You see, the REAL WORLD is my concern. I don't live in a world where I obsess about possible ways things can fall apart.

Now this RTC matter has come up before in different clothing. However, the chips are still the same, and the answer is still the same - doesn't work that way. AND, BTW, the way RTC chips work and hook into other devices IS well known among computer scientists, technicians and engineers - despite Beach's claims to the contrary.

On to why it doesn't matter if the program would fail at a rollover if you can't set the clock. WHERE will the clock start? IF IT HAS NO INPUTS ON STARTUP, IT STARTS AT ZERO - THE SAME PLACE ANY HARDWARE COUNTER STARTS WITHOUT INPUT. The BIOS on a PC sets the date to PC zero date - 1/1/80 - when it starts up without any date on the RTC. That is why you always get the 1/1/1980 thing (depending on the exact BIOS) if your PC battery fails. So if you start a device containing an RTC and provide the RTC with no input, it will start at day one, month one, year one. That gives you over NINETY NINE YEARS of continuous operation without power failures or batteries running down before the rollover event will actually occur. Now if you are not a total newbie to computers, you probably have had a battery run down. So it had to be replaced. And your time had to be reset. Happens to PLC's and such too. AND CAN YOU, EVEN IN YOUR WILDEST DREAMS, IMAGINE KEEPING ANY PIECE OF ELECTRONICS GOING FOR NINETY NINE YEARS? OR EVEN TWENTY YEARS IN THE CASE OF A PC IN WHICH YOU COULD NOT INPUT A DATE? AND industry is not a friendly place for electronics. Power surges are common - just start all the pumps at once at Camp#9 mines and you caused a power surge that could drop the voltage in my lab to nearly 90 volts. Dust, water, heat, humidity, insects, metal grindings, heavy duty accidents involving forklifts and such - the life span of a given piece of electronics in heavy industry is pretty short - ten years would be a long survival time for anything on the line. Moreover, equipment is constantly being updated and replaced as new stuff is brought out. THEREFORE, IN THE REAL WORLD, IT DOES NOT MATTER AT ALL. THE ROLLOVER WILL NOT OCCUR.

Having gone that far, why did the mystery engineers at the mystery oil company find so much trouble? Frankly I have doubts that they did - and you may reach whatever conclusion you wish from that. BUT - if such a place really exists - they introduced a number of really bad failure modes into their tests that would not be present in real life.

FIRST - they replaced a component with another component WHILE THE COMPONENT WAS UNDER POWER. THAT IS A NO NO. First day of the first class in any electronics based technical field you are told - DON'T EVER DO THAT. I have to say they were blowing stuff out by bad testing methods. Did not catch that in Beechs paper? Here is the snip - says exactly what I said it did.

But, there is one that I can remember. It is where they could they would interface the system with an advanced clock. They would watch the system go through the clock change from 99 to 00. Even if the system successfully performed in that function they would then turn the system off and see if they could restart it. Much to their initial surprise, (and I had previously heard this from other engineers) some of the systems would not then restart.

I almost fell out of my chair when I read that! And they are in there soldering away, causing all kinds of thermal spikes and Lord knows what other problems. If it ain't broke, don't fix it.

You cannot interface the system with an advanced clock properly, using the SAME TYPE OF CLOCK AND ASSOCIATED CIRCUITS, without the clock running while you do this, since he specifies a clock that can not be set from the existing circuitry. If you connect it under power you invalidate the test because YOU NEVER, EVER CONNECT CIRCUITS WITH POWER ON. (printer cables and such are different - the input circuits are designed to allow you to plug in a cable or such - he is talking INTERNAL circuits on a l IF YOU USE ANY OTHER TYPE OF CLOCK OR CONTROL CIRCUITS TO ALLOW YOU TO SET THE CLOCK ON STARTING THE MACHINE BACK UP, YOU HAVE INVALIDATED THE TEST FROM THE GET GO. Therefore, you really cannot perform a test on a RTC that has been hooked up in such a blind way. There is no valid way to test the program - any way you can test it will introduce new modes of failure and invalidate the test! AND WHY WOULD YOU WANT TO TEST IT? That one really blows my mind. The machine has been running since power up X many years ago. You KNOW the date in the RTC does not match the real date in any way. You worry about failures if the RTC should somehow rollover. SO FOR HEAVENS SAKE, DO THE LOGICAL THING. PULL THE CLOCK BATTERY AND POWER THE DEVICE DOWN FOR A FEW MINUTES FOR GOODNESS SAKE. THEN IT HAS TO START UP AT THE SAME DATE/TIME IT STARTED AT X MANY YEARS AGO. THEN YOU KNOW BEYOND A SHADOW OF A DOUBT THAT YOU HAVE ANOTHER X MANY YEARS OF RUN TIME.

I just have a hard time believing any group of professionals would behave the way Beech describes - unless they are being directed to by Dilbert's pointy haired boss.

Anyway, don't get your shorts in a bunch over this particular theoretical mode for a microprocessor hooked to a 'blind' RTC to fail. In the REAL WORLD, it is not a worry.

Paul Davis

-- Paul Davis (davisp1953@yahoo.com), April 11, 1999.

Oooohhhh Paul, I feel so much better now. Thanks for your wonderful debunking of another wacko Y2K doomer. Why do they insist on challenging such intellectual giants such as yourself? You must have a REALLY big brain! I hope everyone reads your rebuttal and then donates their food to the Kosovo relief effort.

-- Roger (roger@wilco.con), April 11, 1999.

Those who can, do. Those who can't, belittle those who can.

-- Flint (flintc@mindspring.com), April 11, 1999.

Roger,

great shot! Too bad it didn't print on the target.

Paul, Thank you. this does clear up a bit of the muddle. I still have some difficulties with the remote mainframe controlled processes, but I guess i get to hunt for that one myself. Nice job.

Chuck a night driver

-- chuck, a Night Driver (rienzoo@en.com), April 11, 1999.

Good evening folks. I'm still trying to figure out what the "external clocks" Bruce mentioned really do. See my question above Paul's post. Any comments? <:)=

-- Sysman (y2kboard@yahoo.com), April 11, 1999.

Bruce Beach

-- Bruce (y2k@beach.con), April 11, 1999.

Paul, Sysman, or others,

I have received a lengthy reply from Bruce Beach regarding the above Paul Davis statements. The reply requires a download, which came out on my notepad display, but I don't know how to post that here. So, if you wish to know Bruce's response to this matter, please drop him a note at: survival@webpal.org and then one of you who has the smarts to cut, paste, or whatever, can post it here. :-)

-- Gordon (gpconnolly@aol.com), April 12, 1999.

Thanks Gordon, I just sent him an e. <:)=

-- Sysman (y2kboard@yahoo.com), April 12, 1999.

OK folks, here is Bruce's reply (maybe partial) to Paul. I hope the formatting comes out good... <:)= ----------------------------------------------------------------------------------- My reply------------------> Let me assure the writer that you have identified the correct Bruce Beach. My degree is in Economics, a subject which I taught in addition to computer science. But, my being a Great Grandfather, I sort of got into the computer field under the grandfather clause, because degrees in Computer Science were not that popular when I got into the field. Actually, I had over sixty courses regarding computers, from companies like IBM, Honeywell, Control Data and others. So you will just have to forgive me for being OLD. However, I wouldn't expect you to forgive me for being wrong. I can actually add little to what I said before, but I CAN add a lot more AUTHORITATIVE sources. In the last 48 hours (actually now over 50 hours) since I published the page on the web http://www.webpal.org/Gas.htm there have come to me many, many other sources of sustaining information. I have also had the privilege of dialog with several Ph.D,s (Some of whom I somewhat assume to be in the field of Computer Science, although I cannot know for sure). The end consensus of those who are not greatly concerned seems to be as follows (and these are actual quotes)----------> "Nothing that you say is wrong per se." "the possibility to which you refer does exist but is extemely unlikely" On the other hand, there were numbers more that were not nearly so sanguine, and they provided me with a great number of what I consider to be very authoritative (and usually conservative) resources that quite increased my pessimism over when I wrote the article. Still, I do not know the answers, and I willing share with everyone such information as I have on which to base such conclusions as I have. First, before I clarify some terms, I do NOT wish to apologize for not using "professional" terms like "oscillator" and "RTC" because it is the very use of such well defined concepts that leads to confusion when trying to explain a new and different concept, particularly in terms that can be understood by the layman. Still, while every knowledgeable professional could understand that by the PRIMARY clock, the heart beat, the drum beat, that I was referring to what they call the oscillator-- there was still confusion about what I was referring to as an External Clock By the External Clock, I meant what most of the correspondents refer to as the RTC. (Real Time Clock). Most of the responses referred to only these two types of clocks but I tried to distinguish a third type of clock, which some of the correspondents also discussed, but which they also identified as a RTC. It was to avoid this confusion that I described a SECONDARY clock and how it could be conceptually distinguished. Jerry B (skeptic76@erols.com) described very well the confusion: "Bruce uses the terms primary clock, secondary clock, and external clock. He clearly describes what he means by the term primary clock; it is simply an oscillator. His term secondary clock seems to refer to what most would call a real time clock (RTC). Unlike what he calls the primary clock, the RTC would keep track of dates, and could have Y2K problems. Whether or not the RTC might have Y2K problems, software that uses it could have Y2K problems if the software uses two digit years. Bruce also refers to an external clock, but is not clear what he means by that term." To clarify further the situation: The RTC is the clock that one sets on their PC to give the time of day. The RTC is the clock that the FAA sets ahead when they test the Air Traffic Control system and airplanes. The RTC is the one that the engineers in testing time reliant systems set forward in the 14 tests listed by Michael Harden. (see in the reference at the end). But there is another clock concept, and that is the clock embodied in the firmware. (Heck, another new term. It is not software - that has to be reloaded each time the computer is started. It is not hardware - that is built into the computer and cannot be modified. But it is pretty FIRM and is not easily modified.) This firmware programming is stored as I explained at GREAT length in the ROMs). I should add that when we are talking about PC,s we are only talking about two clocks, the oscillator and the RTC. It is in OTHER devices like PLCs (Programmable Logic Controllers) that we find this third clock concept in the ROMs and ASICs. There is VERY often NO WAY to EXTERNALLY set this clock. That is why I do not call it an EXTERNAL clock and differentiate it from those which can be set externally (ala FAA, NERC, etc). It is true, that this SECONDARY clock (sometimes, many times, maybe even oftentimes) interacts with a RTC that can be set externally, and that it interacts with the RTC and in those cases becomes virtually indistinguishable from the RTC. But there are other times when a SECONDARY clock will not make itself known by either providing, or requiring, external time values, and it is in that function that I have tried to distinguish it by a separate nomenclature. Other respondents to the forum also clearly identified how these "program clocks" (gee, to use another expression, I am just full of them) are developed and came to be embedded in the software (firmware), with no current documentation to describe their performance or parameters. While momentarily, I shall give you the sources for notable authorities views on this point let me also point out that one writer to the forum quoted the following relevant IEEE document (which after describing the tests for PC,s stated -) 1.9.2 Industrial Controllers At this time no test programs have been identified which apply to industrial controls. Without going into more defense of what I said in the original web page, because the facts remain what they are, and other authoritative sources have been found to substantiate them, I will respond to two points in Paul Davis presentation. First and FOREMOST I clearly stated (and I quote DIRECTLY from my original posting): Now comes the interesting part,
as it was explained to me.
These PLC,s are NEVER tested on-line.
EACH and EVERYONE of them is removed from the system,
and taken off-line for testing.

Yet, Paul says quoting me: -------------------------- FIRST - they replaced a component with another component WHILE THE COMPONENT WAS UNDER POWER. THAT IS A NO NO. First day of the first class in any electronics based technical field you are told - DON'T EVER DO THAT. I have to say they were blowing stuff out by bad testing methods. Did not catch that in Beechs paper? Here is the snip - says exactly what I said it did. !QUOTE> But, there is one that I can remember. It is where they could they would interface the system with an advanced clock. They would watch the system go through the clock change from 99 to 00. Even if the system successfully performed in that function they would then turn the system off and see if they could restart it. Much to their initial surprise, (and I had previously heard this from other engineers) some of the systems would not then restart. !ENDQUOTE> ---------------------------- Even in that quote I said they turned the power off. -Bruce --------------------------- Then Paul says:------------> I almost fell out of my chair when I read that! And they are in there soldering away, causing all kinds of thermal spikes and Lord knows what other problems. If it ain't broke, don't fix it. -------------------------- He is really building a straw man here. No where in the article did I suggest in any way or manner that anyone was soldering on live boards. - Bruce ------------------------- Still later, Paul lectures (and the caps are his): YOU NEVER, EVER CONNECT CIRCUITS WITH POWER ON -------------------------- I feel like I am in a discussion with someone who when they can't discuss the point at hand brings up another and then just SHOUTS and SHOUTS about it although I never said anything about soldering to hot boards, and in fact said quite the opposite (see above). -------------------------- Paul states--------------> 1. You cannot interface the system with an advanced clock properly, using the SAME TYPE OF CLOCK AND ASSOCIATED CIRCUITS, without the clock running while you do this, since he specifies a clock that can not be set from the existing circuitry. 2. If you connect it under power you invalidate the test because YOU NEVER, EVER CONNECT CIRCUITS WITH POWER ON. 3. IF YOU USE ANY OTHER TYPE OF CLOCK OR CONTROL CIRCUITS TO ALLOW YOU TO SET THE CLOCK ON STARTING THE MACHINE BACK UP, YOU HAVE INVALIDATED THE TEST FROM THE GET GO. (Paul's emphasis again) 4. There is no valid way to test the program - any way you can test it will introduce new modes of failure and invalidate the test! ---------------------------------- Bruce responds: These four points are exactly what it was the purpose of the article to set out and prove. This points are again reaffirmed by the IEEE quote above. What more can I say, except that through the kindness of others there have now come to me many other documented authorities saying the same thing. Which sources I shall leave you with momentarily. ----------------------------- Now Paul says:--------------> ND WHY WOULD YOU WANT TO TEST IT? That one really blows my mind. The machine has been running since power up X many years ago. You KNOW the date in the RTC does not match the real date in any way. --------------------------------- The latter part of this statement answers the first. We know that at some point, at Y2K or relatively soon thereafter, the Secondary Clock can advance to 00. Paul of course is skeptical of this. However, other members of the forum have already explained how that can be, and I did as well, in the article, so there is no need to repeat myself here. Moreover, I will now refer your to a number of related articles that have since been brought to my attention. This is all the evidence that I have. This is all the understanding that I have. These are representative of all the sources that I have. I have already provided you with such poor credentials as I have. I have provided you with as good (circular, foggy or otherwise) reasoning as I have. Based on these you can equally well make up your own mind, as I have. Knowing Paul's "discussion" method, I doubt that I will really be able to discuss with him further, but nevertheless I feel that he really made my points for me, and he well knows in what little esteem he would hold my capacity for responding, anyhow. Peace and love, Bruce Beach survival@webpal.org =========================================================== The references that I have received in the last two days--------------> I thought you might be interested in knowing of my white paper........ Paula D. Gordon, Ph.D. Visiting Research Professor and Director of Special Projects, Research Program in Social and Organizational Learning, School of Business and Public Management George Washington University Please direct all communications to pgordon@erols.com Http://www.gwu.edu/~y2k/keypeople/gordon ----------------------------------------------------------- Executive Summary: A Working White Paper on Y2K "A Call to Action: National and Global Implications of the Year 2000 and Embedded Systems Crisis" February 25, 1999 by Paula D. Gordon, Ph.D. Director of Special Projects George Washington University Research Program in Social and Organization Learning (The White Paper and accompanying Selected List of Y2K References and Resources are available at http://www.gwu.edu/~y2k/keypeople/gordon.) ----------------------------------------- (I have taken the following complete statement from the above - Bruce) According to Dr. Gordon, Y2K is not a solvable problem. She believes that all that we can do now is to work as smartly and rapidly as we can to minimize the damaging impacts on all fronts. The primary emphasis of the President's Council has been on information gathering, monitoring, assessing progress, and coordinating communication and activity ~ approaches which are neither crisis-oriented nor adequately designed to minimize to the extent possible the harm that can be expected, such as: ~ the failure of weapons systems ~ the failure of nuclear power plants ~ the failure of chemical plants (80% of the American public live within close proximity to a chemical plant), ~ the failure of pipelines and refineries, ~ the failure of hazardous material sites, etc., etc. (note particularly the mention of refineries - Bruce) ------------------------------------------------------------------------------------ The following is an interview similar to the one that we did, but at the U.S. Postoffice-----------> During the tour of the Old Post Office Building on Thursday, March 4, I heard several people say that only embedded systems that the manufacturer said were date sensitive were being tested and that other systems (presumably including those which were only "time" sensitive) were not being tested. Perhaps, the statements that I heard were something of an oversimplification of what is actually being done. But in speaking with the technical people in the computer room who were describing the testing process, I got the impression that they were not aware that time sensitive embedded systems needed to be assessed and tested. For instance, when time sensitive embedded systems are integrated with systems that use real time clocks, it is necessary that all the components of the integrated system be tested. References on the need for assessment and testing can be found in the September 1998 Datamation article (The World's Biggest Easter Egg Hunt" at http://www.datamation.com/PlugIn/issues/1998/september/09y2k.html -------------------------------------------------- Michael Harden's list of fourteen things to look out for when assessing embedded systems. This list appears in Harden's book Millennia Minefields Century Technology Services and in the above Datamation article. 1. Does the system display or print a date or time? This would indicate some type of date function is integral to the operation of the device. 2. Does the system produce regular reports? If reports are generated by the device, and dates are part of the report, there may be a problem. 3. Does the system store historical records? If dates are stored, they may also be manipulated and sorted. 4. Does the system time-stamp data? If a system date-stamps records, logos, or products, it will likely be dependent on utilizing a date that may not be able to handle the year 2000. 5. Does the system implement a timed sequence? If the system starts or stops a function based on date or time, it may have a problem. 6. Does the system perform an operation on a time or date basis? Systems that perform a function based on date or time, such as locking doors on weekends, depend on the correct date. ***7. Does the system perform a calculation based on the differences between time or date? Systems that determine intervals, averages, or total times could be at risk for year 2000 problems. 8. Does the system request the date/time on start-up? When power is turned on, a system dependent on date may request it as input. 9. Does the system send date or time information to other systems?. If a system receives date information from other systems, it may have a date problem. Systems that must synchronize themselves with other systems will typically be dependent on knowing the exact date and time. 10. Does the system receive date information from other systems? If it doesn't have a date problem, it may be dependent on another system that does. 11. Does the system have a command that allows the date to be set? If the device or system allows a date to be input, there is likely a need for a correct date. 12. Does the system know which day of the week is based on a particular date? For example, if the system can tell that June 1, 1998 is a Monday, then some kind of calendaring function exists, and consequently a year 2000 problem is likely. ***13. Does the system generate an alert based on some type of interval? If a system creates some kind of notification based on an elapsed period, an elapsed time counter may be involved, which has no date problem, but a real time clock may also be involved, which does. It is difficult to know which is being used, so these systems are suspect. 14. Does the system display or print data based on a time sequence? Logs or listings of events by date or time indicate a dependency upon knowing the correct date. (This list is typical of the type of list that concerns me. The question is always one of obvious time dependency. Only items 7 and 13 can be construed to involve the type of problem that I think is most serious because it is the least obvious. - Bruce) -------------------------------------------------------------------------------------- The following is a response from a very respected authority in the field, when he was sent a query on the subject by one of my readers--------> Mark Frautschi : 3/10/99 I believe that the logic "If it does not use dates, it is Y2k immune" is rooted as much in common sense (which, unfortunately, in this case is wrong) as in wishful thinking, an unfortunate combination. It may be useful to emphasize that the failure rates are low for embedded systems overall, and that for systems that do not "need" dates, the failure rates are even lower. This is a minority of a minority. Larger haystack, fewer needles. Thus the outcome of this failed logic happens to be right, in the overwhelming majority of cases. But not all cases....... ----------------------------------------------- The following was sent to me this morning: California State Water Resources Board Summary of YEAR 2000 Embedded Systems Issues http://www.swrcb.ca.gov/html/y2ksumry.html Based on experience, it takes 21 months to inventory, analyze, fix and test the embedded systems in a small to medium sized plant. Testing of embedded chips must be done very carefully; there are instances where tests have damaged chips beyond repair. Testing of embedded microchips can be very complex, requiring trained specialists with specialized equipment. Approximately 10% of embedded chips have date functions. Approximately 4% of those may not be year 2000 compliant. That equates to an estimated 160 million non-compliant chips in the world. Just because a chip does not perform a date function does not guarantee it will work properly after 1/1/2000 (date sensitive chips have been used in devices that do not perform date functions). Just because an embedded chip works properly on 1/1/2000 does not guarantee that it will continue to operate properly after that. There are over 30 tests that must be performed on each embedded system to ensure that it is year 2000 compliant. Vendors of electronic devices cannot be certain that they are year 2000 compliant (therefore, all devices must be tested). Just because one device is Y2k compliant, there is no guarantee that all other devices that have the same manufacturer, model, version, lot number, etc. will also be compliant (therefore, all devices must be tested). A system containing numerous Y2k compliant embedded microchips (from different manufacturers) may not be compliant, because there is no date standard followed by all manufacturers. It will not be possible to test all embedded systems and repair the non-compliant ones (therefore, efforts should be focused on the most critical systems). It is possible that major utilities (electric, telecommunications, water, etc.) will be unable to operate for some period of time after 1/1/2000 (therefore, it is essential to have a contingency plan). Businesses will be held legally responsible for damages caused by non-compliant embedded systems. (This California Water Board statement shows that some organizations are aware of what I am saying. However, one must still wonder how many are not. For those who are not, the 21 month lead time is far past. And this is not something that one can hurry up and do in 9 months. It may still be possible to have a baby before the new year, but it is NOT possible to remedy all the Y2K systems in a large facility if one has not started long ago. - Bruce) ---------------------------------------------------------------- (And here is a VERY conservative and responsible web page that REALLY reinforces what we discussed and found. - Bruce) http://www.jsonline.com/bym/tech/0214chips.asp (Look particularly at the Occidental petroleum experience. -Bruce) ------------------------------------------------------------- (And compare our experience with this attributed to Chevron. I do not have an original source. - Bruce) Because of the scope of Chevron's operations, the company believes it is impractical to seek to eliminate all potential Year 2000 problems before they arise. As a result, Chevron expects that its Year 2000 assessment and corrections will include ongoing remedial efforts into the year 2000." "While the company believes that the impact of any individual Year 2000 failure will most likely be localized and limited to specific facilities or operations, the company is not yet able to assess the likelihood of significant business interruptions occurring in one or more of its operations around the world. Such interruptions could prevent the company from being able to manufacture and deliver refined products and chemicals products to customers. The company could also face interruptions in its ability to produce crude oil and natural gas." ------------------------------------- (And while this one is a bit off topic, and much less a problem, it still is quite informative. - Bruce) http://www.iee.org.uk/2000risk/w-87.htm ----------------------------------------------- (And some people might find this a real eye opener from a very responsible source. - Bruce) http://www.chemsafety.gov/y2k ------------------------------------------- (And here is still ANOTHER that is much the same. - Bruce) http://www.news.com/News/Item/0,4,33752,00.html -------------------------------------------------------

-- Sysman (y2kboard@yahoo.com), April 12, 1999.

So much for the formatting... <:(=

-- Sysman (y2kboard@yahoo.com), April 12, 1999.

I hesitate to enter into a detailed embedded systems discussion, since that is not my area. But it appears to me that the author is describing, in a roundabout way, what has been known as the "hidden date" problem in embedded systems.

As such, I thought this info from 3COM might be useful:

3COM Link

Are there any 3Com products without a time or date function but could have a "hidden" component of their subsystem with a date function which could be affected by Year 2000?

3Com works very closely with its suppliers and we believe that there are no products which have this problem, sometimes described as a "hidden" Year 2000 issue. For any device to understand the date and time there has to be some input at the factory or by the user to define the initial time/date. If this is set at the factory, some power source is needed for the time and date to be kept and as there are multiple time zones around the world, the factory would have to know the correct time zone of the end user. Though the possibility of this problem occurring has been discussed in some articles, we have no evidence of any manufacturer of any product in the world who has this problem. It can further be stated that 3Com does not set time and date functions on any products which do not also have the ability for the user to reconfigure the dates and times. This demonstrates clearly that no 3Com device suffers from this alleged problem.

-- Hoffmeister (hoff_meister@my-dejanews.com), April 12, 1999.

Geeezz Hoffmeister, thanks a lot. If I only had read that statement at the beginning of this thread, say at spot 2 or 3, I wouldn't have wasted so much time reading and thinking about this situation. (slap forehead with palm of hand, 3 times, real hard)

-- Whetherman (whetherman@storm.warning), April 12, 1999.

Good afternoon Hoffmeister. Yes, the 3Com post is good news. However, this is ONE vendor out of ?????? <:)=

-- Sysman (y2kboard@uahoo.com), April 12, 1999.

Sysman,

I think you might have hurried past the most important part of the 3Com statement. They are saying that they don't think there is any vendor in the Entire World who has this problem. Isn't that just fantastic? So let me see, there are not going to be any catastrophic software OR embedded system problems coming down the pike. I think it's safe for me to put my portable generator up for sale immediately and put the money back into the booming stock market. Yep, yep, that's it. And then back to bed for a good snooze. What a relief!

-- Whetherman (whetherman@storm.warning), April 12, 1999.

No Whetherman, I noticed it. I just figured that such an outlandish statement, coming from a company that got it's start manufacturing Ethernet adapter cards, that have absolutely no date or time functions, should just be ignored. <:)=

-- Sysman (y2kboard@yahoo.com), April 12, 1999.

Gee, guys, sorry to introduce actual statements from actual manufacturers into your little world of conjecture and speculation.

By the way, Sysman, isn't the discussion about components that have no actual date functions, but that supposedly may fail due to secondary issues?

-- Hoffmeister (hoff_meister@my-dejanews.com), April 12, 1999.

Hoffmeister, my take on this discussion is long term "counters" that are initialized to zero when powered on, and may overflow some time later. For 3Com to make this statement about every digital component manufacturer in the world is more than outlandish. It would be comical if this wern't such a serious issue. <:)=

-- Sysman (y2kboard@yahoo.com), April 12, 1999.

Sysman, yes, that is the discussion. And maybe I missed it, but nowhere did Beach address the point made by Paul Davis; that, if initially set to 0, we're talking about a 99 year time frame (of continuous power) until failure.

-- Hoffmeister (hoff_meister@my-dejanews.com), April 12, 1999.

Wait a minute, wait a minute! I had just put my generator up for sale and told my broker to get me back into the market and laid down for my well deserved rest, when it hit me. If I have heard it once I have heard it a dozen times from the Polly crowd. "Never trust information or statements issued by people who are trying to sell you something." Made me sit right up straight. If they're right about that then the 3Com outfit is not to be trusted, or their opinions on vendors all around the world. Darn, darn. The generator is back off the market, and the stock order is cancelled. I'm just getting so *confused* about all this stuff.* I guess I'll just go back to reading all the good old personal attacks which don't require that I do any serious thinking about basic issues. Sigh.

-- Whetherman (whetherman@storm.warning), April 12, 1999.

That 3Com statement smacks of lawyerese. "We have no evidence" of any problems in the world. And if they did, how would you know? You have no evidence of that either.

I consider their statement highly likely -- it would take real effort to design something to fail in this way. For what it's worth.

-- Flint (flintc@mindspring.com), April 12, 1999.

Flint, I see program checks caused by various overflow conditions, including divide by zero, on the mainframe on a regular basis. It doesn't take any "real effort", just an oversight by the programmer. <:)=

-- Sysman (y2kboard@yahoo.com), April 12, 1999.

Sysman:

I wasn't clear. In order not to have the clock reset when power is off, you have to design in a battery or large cap. You don't do that by accident. In order to prevent clock drift over time, you must engineer in some method of keeping the clock synchronized with the outside world, that does NOT include having anyone ever reset that 'hidden' clock. You don't do this by accident.

Now, you might be taling about code that mishandles a century rollover, in the unlikely or unlucky case where the device is continuously powered (somehow) and synchronized (somehow) without being settable (somehow) in some unknown time zone, after an undefined period of time. Yeah, could be. But these are going to be extremely rare events, and extremely sporadic. NOT something that strikes at midnight around the world on one night worldwide.

-- Flint (flintc@mindspring.com), April 12, 1999.

Good evening Flint. Since you mentioned clock synchronization, please review this thread (starting just after my post on the ROM burner), and give me your comments on what the role of the "external clock" is. Thanks. <:)=

-- Sysman (y2kboard@yahoo.com), April 12, 1999.