A poster to a recent thread about four plane crashes raised the issue of annual maintenance scheduling and wondered if there might be a chance that it would be playing a role. (That thread is at http://hv.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=002Nls )

I had talked with a software engineer about annual maintenance scheduling a few days before the posting. He told me on that annual maintenance scheduling triggers a diagnostic self-check. That entails the recording of a date and time. If the date did not roll over then the PLC can seize and this can result in "functional overflow". Here is the exact wording that he provided me concerning "functional overflow": "Functional overflow is the name given to either of two conditions. In one case, the function (procedure or basic 'task' that a program might perform) overflows the memory space allocated to it. This occurs because it retrieves some data (such as a date) from an area in RAM which is larger that it can accomodate within the variable size within the function. In other words, the function has allocated 26 bytes and the date comes back as 28 bytes. This overflow could cause a problem in a number of circumstances such as, if that variable is used in a calculation, if that variable space is passed back from the function, if adjacent variable space is accessed (it would be corrupted in a pass-by-reference function). As with other software, when the data steps outside the range allowed by the programmer, things aft gang aglay (get snafu'ed).

The other basic functional overflow occurs when spaces allocated to a function cause an overflow error within the OS of the device. In this case, the device's operation as a whole is threatened. The limiting factor is how well crafted might be the exception handling within the OS of the device. As a general rule of thumb, you can figure that the smaller the device (chips, systems, et cetera) the less room there is for robust error handling, so ......."

(End of quoted material. This material has been quoted in its entirety.)

Another problem with annual maintenance scheduling is that the exact date that the date function is activated is the same date every year, but that date is by no means the same in everything that has annual maintenance scheduling.

Annual maintenance scheduling is by no means unique to airlines. The list may be endless. It includes for instance chemical cooling wells.

-- Paula Gordon (pgordon@erols.com), January 24, 2000

Answers

Functional overflow can be caused by the same problem that causes the year=19100 and year=100 problems - programmers think the year value for some programming languages will be 00 when it will in fact be 100 (don't ask! someone obviously thought this would be a clever idea at the time - computer people love these oddities that only the real experts know about).

Try putting 100 into a storage space that expects only 2 digits and you can get a corrupt unusable value. Worse, it can overflow on top of something in the program that was really important and this could cause ANYTHING to happen.

This problem happens in the programming languages C, Perl, Java and Javascript (and a few others besides). Embedded systems can be programmed in C and possibly Java as well. However, the overflow onto something else aspect to the problem only happens with C.

The interesting thing about the year = 100 and year = 19100 problem is that it is just a programmer bug and some would argue that it is therefore not a Y2K problem which have supposedly been designed to happen. It is just a 'normal' bug so doesn't have any connection to Y2K. Right?

-- pgmr (pgmr@pgmr.com), January 24, 2000.

It's not a bug. It's a feature.

-- I'm Here, I'm There (I'm Everywhere@so.beware), January 24, 2000.

Paula STOP!

Please stop coming up with this kind of thing. If there were anything to it then there are people who would know about it. There is no mystery to all of this, people exist who know exactly how these things work. Computers did not mysterously appear with to us without any knowledge of how they work. There is no area, no chip or wire in a computer or embedded systen that was not planned, its attributes were designed into them.

Why don't you stop all of this nonsense, give it up, put it away and move on to something else. There are REAL problems in the fuel industry, the aging and under maintained pipelines are breaking down and plants are exploding often enough now to be a dager to the lives of people, there is a real need for the poor maintenance and lax upkeep to be exposed.

The JAVA caused date problems (19100 etc) have nothing to do with what you are suggesting about embedded chips/systems.

You are grasping at straws, trying to figure out a way there is going to be a problem where there isn't one. I cannot sit here and explain digital functioning in a way that you can understand, it is too technical to understand with out a lot of training.

I wish you would understand that being a software engineer means nothing. A programmer may understand what the software does, but they do not know what it physically does. Software is just a way for humans to grasp and manipulate what a computer does. It goes through the equipment as electronic pulses in base two. Software engineers (programmers) do not know or understand how those pulses move.

And especially today when programmers usually are very specialized in what they do and seldom understand one form of programming from another, much less the arithmatically logical way the program works down at machine leval.

You keep trying to say that getting the date wrong will some way cause an overflow. The machine uses a mathimatical base of two to calculate, we use base ten. What causes an overflow in base ten will not cause an overflow in base two. I am not going to go into detail about assigned column widths or trunctuating, but if your programmer friend never mentioned them, then once again, this person was not explaining what was happening in fact as opposed to theory.

No matter how you try, how much you wish it to be true, it is not.

The continuation of blaming everything on Y2K and embedded failures due to Y2K is doing nothing but causing the real reason for those failures to be ignored.

It's over.

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

"it's over" ...

LOLOLLOLLL .....ROFLMAO .....

sorry .. just couldnt help it.

-- lou (lanny1@ix.netcom.com), January 24, 2000.

The continuation of blaming everything on Y2K and embedded failures due to Y2K is doing nothing but causing the real reason for those failures to be ignored.

Cherri, who is ignoring the real reason for these failures?

If everyone is so expert as you, then they all realize that there are no Y2K failures, so the causes must be elsewhere. Right? Then, why are they not working on correcting those failures?

But, obviously, everyone is not so expert in so many things as you, otherwise all those governments, federal and state, would not have spent so much money on their bunker, eh? Let alone all the money they spent on remediation.

And, why take several paragraphs to state the obvious:

99 in binary is 1100011

100 in binary is 1100100

So, both require 7 bits. Therefore there shouldn't be an overflow problem. (Notice that I didn't say won't be a problem.)

-- rocky (rknolls@no.spam), January 24, 2000.

Cherri: I'm going to take a stab in the dark that "pgmr" stands for program manager. This person, obviously, has also heard of functional overflow. I'm no computer expert but I can say that Paula Gordon is not making this up. Even if you would like to think she is.

-- Shoo (flyonthewalls@yahoo.com), January 24, 2000.

Cherri,

And the real reason for all these failures is? ___________?

If not Y2K, is it offensive information warfare? Who - China??? Is that what you mean by its over?

Please fill in the above blank and identify the root causes, the duration and the severity of the known failures to date since you are so smart.

Personnaly, it seems rather moot whether the developing oil crisis is a Y2K event or something else. It seems we may need our Y2K preps soon enough. Lets discuss "systemic failures of unspecified origin".

-- Bill P (porterwn@one.net), January 24, 2000.

Cherri, with enlightening posts such as yours above, it is awesomly obvious that things can/will? really screw up.

True enough, as you indicate, Y2K didn't land on a vacuum. Yes indeed, pipes are corroded (many unrepairably corroded), people do have flu just when you may most need them, a fuel crisis means heating problems, freight problems, banking & political problems (both here and abroad, think Russia-Germany, Brazil, Japan), etc, etc, which just makes things WORSE, not better, as all of these real- life problems don't help ANY to fix Y2K, unless you mistakingly take for granted that it fixes up all by itself, without any investment in IT staff time, money, or other resources, without any patches, fixes, further remediation, etc. And then you have the specific Y2K aspects such as the February 29 issue, the EOM issue, the hard-coded dates issue, buffer fill-up issues, etc., etc, which further compound on the chronic, expansive nature of the problem.

This thread clearly shows that nobody yet knows the ethiology nor the epidemiology of the Y2K bug. Until we do, no-one should declare that the Y2K bug is dead. This whole thing reminds me so much of the 1980's initial scenarios of AIDS that it ain't funny.

So Cherri, if your answer above is the best you can do for the polly position, the least I can say is that you make me feel very uncomfortable (not that it's your fault!). Your posts do help though to see things in perspective and to understand how much we have yet to see from Y2K.

Take care.

-- George (jvilches@sminter.com.ar), January 24, 2000.

I don't doubt that functional overflow can happen but I don't see anything here to indicate that it is a big deal. I doubt that anyone has done any kid of impact analysis huh Paula? Is this just something else that you want us all to worry about?

I last heard you (Paula) worrying that the recent holiday (3-day) weekend which you thought would cause all sorts of havoc due to day- of-week calculations. Where are the problems? Before that it was all sorts of doom and gloom about embeddeds and all those chapters to your white papers. You said things were going to be disastourous but they weren't were they?

Now this... How many times can someone "cry wolf" before they stop? I guess there is no limit. I for one join Cherri in pleading for you to shut-up and go find some other windmill to tilt at....

Skeptically yours

-- Skeptic (Dont@believe.it), January 24, 2000.

Hi Skeptic -- did you know you have the exact same IP number as Nut on the Jim Lord thread? And it bears an uncanny resemblance to Peg's IP over at Bonkers too.

-- Sysop (on@troll.patrol), January 24, 2000.

Yeah really Paula! Everyone knows the REAL cause of all these mishaps is RUST.

-- Rusty (@ .), January 24, 2000.

Hi Skeptic -- did you know you have the exact same IP number as Nut on the Jim Lord thread? And it bears an uncanny resemblance to Peg's IP over at Bonkers too.

-- Sysop (on@troll.patrol), January 24, 2000.

Sysop...

Check it again.

I'm not Skeptic and I don't appreciate your accusation.

-- Peg (pegmcleod@mediaone.net), January 24, 2000.

pgmr = programmer

That at least some programmers misunderstand the year value is evident by the number of time 19100, 100 or 1900 appears on web pages.

Just because you can store 99 and 100 as a binary number does not mean that programmers have done so. Also, it depends on how the programming language itself stores numbers - the programmer often doesn't even think about it. COBOL gives the programmer a choice about how numbers are to be stored - not many other languages do.

Its clear that embedded systems programmers are capable of making Y2K problems as well as ordinary programmers. Who else is responsible for the documented medical equipment failures and other types of equipment failure which has been proven to be Y2K related?

Sure, Cherri was right that nothing catastrophic has happened so far with Y2K, but I have read her flawed reasoning for this. Her lack of real knowledge on many if the aspects she attempted to explain was a real concern. If she is one of these 'experts' responsible for our embedded systems then we have scraped through this mess (so far) despite such 'experts', not because of them.

The real questions are how many embedded systems have date functionality, how many of them have a Y2K problem, if they do have a Y2K problem will it cause a problem, will the problem be serious and will it occur in any equipment that is critical.

Perhaps the percentage is extremely small but if it is enough to cause all the current refinery problems (train and planes disasters? etc.) then we do need to look further into these problems.

The "Im right, you're all wrong' attitude that Cherri has been churning out for the past 18 months or so has not been helpful. At least her spelling and grammar has improved dramatically and she can thank the Y2K issue for that!

Perhaps now that she can write a readable sentence she could offer a lucid insight on what she does know about embedded systems from real life experience rather than what she assumes or guesses.

-- pgmr (pgmr@pgmr.com), January 24, 2000.

pgmr: I was close!

-- Shoo (flyonthewalls@yahoo.com), January 24, 2000.

Paula, Aw, did you have to go and do this, after all of your other warnings of the "embedded systems crisis" failed to materialize, and even after I even wrote you an apology and left e the forum? But someone emailed me your latest post and, wellI just can't resist this one, consider this a guest appearance. I guess I will do so when I am so "moved" by myths, speculations, and generally bad information that someone emails me. Nothing personal Paula, I like you, but this information is, well, pretty bad. Ok, its real bad. But I will try to just stick with the technical issues.

Maintenance dates. They do exist - in software programs that tracks maintenance, or in rarer cases as "date stamped" information in an embedded system memory chip. A program might be on a PC or mainframe computer, print out a work order and get scheduled to have a technician perform the maintenance. Generally, this might cause an error in performing scheduled maintenance if there is an error in the maintenance date (due to y2k or any other cause). Yes, I have seen some PLC applications do periodic diagnostics  but NOT on an annual basis like a maintenance interval. And would be quite surprised to see one lockup on such a cause. Can you please ask your programmer friend to provide us with the manufacturer and model number of the PLC? Something's not quite right about the information about that either (perhaps something got lost in translation from your friend to you?) ...I wan't to check the date storage format of the PLC that is being cited...and the "buffer" problem...

For embedded controllers, shutting down a control system or doing ANY CONTROL FUNCTIONS based on a MAINTENANCE DATE interval is something I have never seen in 20 years of working with instrumentation and control systems. I do know that in rare cases some controls may use dates for controlling, but havent seen MAINTENANCE DATES (like the ANNUAL ones you cite) used for controlling, I have only seen these kinds of dates used as date stamps. I have seen a manufacturer store what could be called a "maintenance date" for historical reference in an embedded system, but this was just like putting a date tag on the device - the date wasn't used by the system, only by the manufacturer to see when the device was last calibrated. My experience and research doesn't mean that CONTROLLING on "maintenance dates" hasn't been done somewhere -it's a big world, somebody probably has, but if its done at all its rare. In all of my work in research in Y2k in the electric industry, I never found a single example of the oft cited "maintenance date" failure. (self diagnostics of PLCs is unrelated to scheduled maintenance dates that might be set for certain types of equipment and is a separate issue, and I have never heard the two tied together until this thread.)

To just lay out the possibility that there might be such a "maintenance date" shutdown of an AIRCRAFT FLIGHT CONTROL SYSTEM that could cause a crash, as you have above, is quite an extraordinary insinuation - that deserves extraordinary evidence.

So heres the challenge to you Paula (and no one else, this is your thread, after all :) - if you can provide documented evidence from the manufacturer of an aircraft that has an embedded system device on one of their planes that will stop a part of the planes FLIGHT CONTROLS from functioning BECAUSE OF A MAINTENANCE DATE, I will send $50 to the charity of your choice. It doesn't even have to cause the plane to crash, it just has to be a FLIGHT CONTROL that could cause the control to MALFUNCTION or STOP due to a MAINTENANCE DATE. And no, the Boeing problem they give on their website regarding the FMS and NDB doesn't support you, in fact, Boeing states: ----------- http://www.boeing.com/commercial/aeromagazine/aero_03/textonly/sy01txt .html

AIRBORNE SYSTEMS WITH DATE EFFECTIVITY CHECKS. The survey revealed that the only airborne systems checking date are those containing an embedded navigation database (NDB). (See "Regulatory Requirements for Current Navigation Data") Though recording and maintenance systems use dates, they do not perform any processing based on those dates or use the month/day format only and so are not susceptible to Y2K problems. The affected systems include the FMS and INS. --------

Oh, did I mention that I've never heard of an aircraft using what's commonly called a PLC for controlling flight?. Can I have that make/model as well? I guess I thought flight controls were much more dedicated and specialized, so if there's an Allen-Bradley, or a GE Fanuc, or a Modicon PLC controlling flight in a commercial airplane, this is really, really, news to me. I would use one in an experimental home-built though, as long as I had a manual backup ;) I'm back. I'm ready to rumble.

-- FactFinder (david@bzn.com), January 24, 2000.

Cherri: You keep trying to say that getting the date wrong will some way cause an overflow. The machine uses a mathimatical base of two to calculate, we use base ten. What causes an overflow in base ten will not cause an overflow in base two.

You have just exposed yourself as being totally ignorant of the basics of microprocessor operation. Even I, even though I am not an "embedded systems expert" like you claim to be, know that microprocessors have BCD arithmetic capabilities that are used whenever you want to save conversions from display to calculation format. If the date is stored in BCD, as it may very well be to save on these conversions, there WILL be overflow problems when you try to add "01" to "99" to roll the year forward.

If you try to deny this, I'll find the spec sheets on some of the more commonly used microprocessors and post references to them on this thread or another one.

Goodbye, Cherri. Go back to "Debunkers" where they will worship your "expertise" and ignore my demonstration that you are anything but an expert. We don't need your lies and/or ignorance here anymore.

-- Steve Heller (stheller@koyote.com), January 24, 2000.

Tsk Tsk Steve, Don't you think that since Cherri was right on about y2k and embedded system as proven, thats right, proven by the rollover....and your speculations were um, to put it kindly, out of the ballbark accuracy wise, that YOU might want to consider just a "little" humility?

Just a though....and please feel free to take a crack at my post above :)

-- FactFinder (david@bzn.com), January 24, 2000.

Ms. Gordon: Like David/FactFinder, I have Y2k testing experience with embedded systems. And I agree with his technical analysis of this and the other posts of yours on embedded systems--this is most likely an inaccurate hypothesis.

In my work in the power industry, the embedded systems that run diagnostics do so in real time, that is they are basically always running self-checks. If they find an error, they close an output contact that is typically wired to a SCADA system so that the alarm is sent back to the control center. Then a human sees the alarm, and depending on its severity, calls a technician out to the site to check out the device. I've never seen an "annual check" in a protective relay or PLC used in a substation.

Think about it logically...for a critical device, would you want it to run a diagnostic only on an annual basis?

There are circuit breaker monitors that calculate the amount of energy interrupted by the breaker, and when that threshold is exceeded, the monitor sends out an alarm. But this algorithm is separate from the date function, so a date change won't cause the alarm to be sent.

Finally, literally thousands upon thousands of embedded systems have been analyzed by subject matter experts on this and other issues. Our test results indicated that none of these devices would fail catastrophically due to a date change.

So, is this hypothesis entirely from the "software engineer", or did you take this person's information and extrapolate it to suggest that there would be a problem?

-- Dan the Power Man (dgman19938@aol.com), January 24, 2000.

Tsk Tsk Steve, Don't you think that since Cherri was right on about y2k and embedded system as proven, thats right, proven by the rollover....and your speculations were um, to put it kindly, out of the ballbark accuracy wise, that YOU might want to consider just a "little" humility?

Let's try a little thought experiment. Suppose person A has predicted the price of crude oil correctly, whereas person B has predicted it incorrectly. Then let's suppose that person A makes the claim that "2+2=5", whereas person B makes the claim that "2+2=4". Which would you listen to?

To apply this to the present question, it is not a matter of speculation whether, as Cherri says, "The machine uses a mathimatical base of two to calculate, we use base ten.", or, as I say, "microprocessors have the built-in capability to do decimal arithmetic". It is a matter of fact. As it happens, she is wrong, and I am right.

For example, the Z8 0 instruction set includes the "DAA" instruction, which stands for "Decimal Adjust Accumulator". This is used to correct the results of using the standard ADD and SUB instructions to add or subtract two numbers stored as BCD (Binary Coded Decimal) data.

More directly, the 68000 instruction set includes the ABCD instruction, which adds two 16 or 32-bit BCD values to produce a BCD result, with a carry for dealing with longer values than will fit in a register.

I'm not familiar with every microprocessor, of course, but most if not all of those I have used have had similar built-in facilities for doing decimal arithmetic.

Of course, as embedded systems have historically been short on memory and often on processor speed as well, any embedded systems expert would have to be fluent in the assembly language of the processor in question, which would mean that he or she would have to know about these decimal arithmetic capabilities. Therefore, we must conclude that there are only two possible explanations for Cherri's claim that machines use base 2:

1. That she isn't really an embedded systems expert at all; or
2. That she is deliberately lying about the methods by which these machines do arithmetic.

Of course, I could conclude that she's a liar either way, because she has claimed expertise which she doesn't have (if she isn't deliberately lying about the decimal arithmetic). However, I'd prefer to be charitable and accept the possibility that she really believes she is an embedded systems expert, regardless of the clear evidence to the contrary. Incorrect beliefs, no matter how deluded, do not make one a liar.

Hope this helps.

-- Steve Heller (stheller@koyote.com), January 25, 2000.

Dan, Thanks for making this much clearer than I did. You have a way of adressing the issues without a lot of fanfare, I like that.

Steve, Thanks for the reply. I truly love it when someone provides facts, and the MP examples were very good, thanks. Look, I have nothing against you personally, never did, I thought the debate you and Hoff had was admirable, the way you both conducted yourself. Not sure if you noticed, but at debunkers I said I would not hold anyones views against them in deciding whether or not to buy a book they wrote.

I stated here once that I thought that there was no such thing as an "embedded systems expert," but I meant that in the context of Y2K in embedded systems. To "know" how y2k will affect a given piece of equipment, you have to know more than the microprocessor (actually, you don't even have to know this), you have to know how the device itself, what it's functions are, how dates are used, and how y2k dates affect the devices performance and date handling. There are so many ways to get there, by testing, by "knowledge" of date formats and storage and transmission, etc.

An embedded system programmer may know how dates are handled for the devices he/she has programmed, but unless that programmer has worked with thousands and thousands of kinds of computerized equipment, the programmer is not going to be an "expert" on Y2K in embedded systems.

I submit that the closest to being "experts" on "Y2K in embedded systems" are those that have been involved in the testing of the devices, they see a wider variety of devices, but even they are not experts, just more knowledgable than most.

Back to your comments on Cherri. Hey, if you know microprocessors to any degree, you know far more than I do about them. The one thing I THINK I know about some of them is that they have a "clock" pulse output used for timing in some cases, and dates in some cases (DOS clock, but correct me if I am wrong, lol).

I took Cherri's reply, at face value, that indeed, the MPs do the calculations in binary, in fact, everything appears to me to be done in binary for a device that has only two transitional states. Further calculations by the microprocessor that process and store the data in BCD format are done in ....correct me If I am wrong, I'm guessing here...binary. I think its a bit unfair to take one sentence, that she may having been thinking about one thing, you another, and infer from that that she is a liar. Hey, even if she made an outright mistake, brain overload, whatever (I do THAT a lot) doesn't make her a liar.

This doesn't take away from the point you make that sometimes the data can be stored in BCD. It really isn't the end-all factor, as far as I can see it, since it sure appears to me that how data is stored can be based on an operating system instructions as well, such as in PLC operations.

How are dates stored in PLCs? Depends on the PLC, there are so many, and I am not an expert, I know a few. That's why I asked. Some A- B's store a four word integer for example. I know at least some PLCs can store in BCD, and I seem to remember at least one that stored dates this way, but don't hold me to that, I fog up when talking 0s and 1s, that's why I don't program, lol.

PLCs can have "overflows", such as math overflows. But this doesn't mean that the system will malfuntion, I believe that typcially an overflow bit is set and the overflow data may be stored to an overflow register, in some cases. Sure, you could program the PLC to stop on the overflow bit, if you wanted to! To assume that an overflow will crash a PLC is assuming quite a lot IMHO. As far as date storage and oveflows, I am not an expert in this area either, there are so many apples and oranges, but I can research if I know the Manuf/Model.

I do know this about PLCs, I have seen y2k test results for hundreds of them come back with no problems or only minor date stamp errors (for the ones that have an RTC, many don't). And in the end, this is what really counts.

And how about this - if a date such as a "maintenance date" has a problem with being too large for its assigned storage area, isn't it likely that on the rollover the storage area for the date was equally too small? What about THAT overflow/overwrite/insert you favorite digital process here. I don't know all the answers to THIS one, but it sure seems likely to me that these speculated "maintenance date used" PLCs wouldn't have done too well at the rollover either...

Binary Mode....OFF, whew, lol.

-- FactFinder (david@bzn.com), January 25, 2000.

Factfinder,

Your analysis strengthens the awesome conclusion that we DO NOT yet know either the etiology and/or the epidemiology of Y2K, i.e., we all know it exists but we don't yet agree on how it acts, how it may react, nor how it could spread.

Until we do, and in light of the importance of possible impact of Y2K, it would be a serious, unforgivable mistake to declare this bug dead.

And for the sake of not arguing with those who don't agree that Y2K is the culprit of what we are currently witnessing, worldwide, let's just call it "SHSIOAAFOUOISMBAACDC" = "Statistically High Significant Incidence Of Accidents & Failures Of Unknown Origin Some Months Before And After the Century Date Change".

Take care.

-- George (jvilches@sminter.com.ar), January 25, 2000.

Not sure if you noticed, but at debunkers I said I would not hold anyones views against them in deciding whether or not to buy a book they wrote.

Thank you. I appreciate common sense.

I took Cherri's reply, at face value, that indeed, the MPs do the calculations in binary, in fact, everything appears to me to be done in binary for a device that has only two transitional states. Further calculations by the microprocessor that process and store the data in BCD format are done in ....correct me If I am wrong, I'm guessing here...binary.

Maybe we have a terminology problem here. Of course microprocessors do EVERYTHING in "binary", as their digital circuits require. However, the rules of arithmetic used by the BCD instructions are the rules of decimal arithmetic. That is, if you have a two-digit value of "99" that is stored in BCD, and you add a BCD "01" to it, using the BCD instruction set, you will get BCD "00" with a carry. This means that the year after "99" is "00", which of course is less than "99". Thus, the statement that "all arithmetic is done in binary in the machine, and therefore we don't have to worry about overflow" is false. If Cherri is really the embedded systems expert she claims to be, she must know this.

-- Steve Heller (stheller@koyote.com), January 25, 2000.

Dan:

You wrote:

>So, is this hypothesis entirely from the "software engineer", or did >you take this person's information and extrapolate it to suggest that >there would be a problem?

-- Dan the Power Man (dgman19938@aol.com), January 24, 2000.

The quoted material is entirely from the software engineer.

The material that does not have quotes around it (beginning in the second paragraph and including the material at the end of the posting was all based on what he told me. He saw the entire write up (including the non-quoted material) before I sent it in and had no problems with any of it.

The reason that he did not give specific examples is owing to non disclosure agreements.

I think that one of the reasons that people may have such differing perspectives on what he is saying is that their areas of expertise may not all overlap with the areas of expertise that he has. From what I have been able to determine, he has an extremely broad range of experience in a wide variety of different sectors.

The people I confer with who have technical expertise in embedded systems often have very different perspectives. The differences appear to be traceable to the fact that each has direct experience in one or more different sectors, e.g. building operations, waste water treatment systems and water purification plants, telecommunications, chemical manufacturing plants, refineries, etc.

I hope that these comments are helpful.

-- Paula Gordon (pgordon@erols.com), January 25, 2000.

Paula,

Please keep the information flowing, whatever the reason for the problems we've been seeing in the nuc's, oilfield, military,... a "heads up" is better than waiting for the next thing to happen.

Thank You - for your persistance, perseverance, and kind consideration for us all.

Best Regards,

-- Tom McDowell (bullriver@montana.com), January 25, 2000.

Paula, Flint, thanks both of you for your private e-mails in response to my post on this thread. I see you both enjoyed my newly coined acronym, FWIW !

And just to follow up a bit further on the subject matter, I was just thinking that, whatever its magnitude, Y2K's significance-to-impact ratio (S/I, right?) will end up being the highest possible because of its unexpected, delayed timing, thus catching just about everybody off guard, at least outside the US.

Take care

-- George (jvilches@sminter.com.ar), January 25, 2000.

Stevie, Stevie, Stevie.

Got your knickers in an unroar when t=you thought you "got me".

BCD is two digit logic. it is put into a form that people can "see".

92=1001 0010. The number is not a deciaml 92, it is mearly written for ease of understanding.You have a bit in the * column and zero in the 4 and 2 columns, for the 2 you have zero zero one zero. While you understand it by base ten it is DONE digitally (base 2). Just because you understand it as a decimal number, that does not mean the computer does, it still computes it digitally.

Booleen algebra has always been one of my favorite subjects, I have used it for decades, as well as knowing how the ones and zero's run through the hardware.No matter what you call it, no matter how you write it, the mathimatical calculations are done by ones and zeros, in the form of electronic pulses going through hardware.

Why do you go to the extreme of calling me a lier?

binary coded decimal

(BCD) Number representation where a number is expressed as a sequence of decimal digits and then each decimal digit is encoded as a four bit binary number. E.g. decimal 92 would be encoded as the eight-bit sequence 1001 0010. It is easier to convert decimal numbers to and from BCD than binary and it is possible to build hardware which operates directly on BCD though it is often converted to binary for arithmetic processing.

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

Cherri,
I don't see the relevance of your last answer to Steve's point, which is that in BCD, adding 1 (0000 0001) to 99 (1001 1001) should yield 100 (0001 0000 0000), irrespective of what base is used to perform the computation. If provisions were made for only two BCD digits in the result, is that not by definition an overflow?

-- David L (bumpkin@dnet.net), January 25, 2000.

No matter what you call it, no matter how you write it, the mathimatical calculations are done by ones and zeros, in the form of electronic pulses going through hardware.

None of which answers the question of what happens if you use BCD instructions to add the BCD value "01" to the BCD value "99". If you're an embedded systems expert, you should know the answer to that question, so either answer it or admit you aren't an expert.

Why do you go to the extreme of calling me a lier?

I didn't say you were a liar, only that you were either a liar or actually believed you were an expert. I'm willing to give you the benefit of the doubt and accept that you believe you are an expert.

-- Steve Heller (stheller@koyote.com), January 25, 2000.

Ok, As much as I don't like it, I'll do the BCD thing. What happens of course depends on the specific system involved, as we all know. In Paula's PLC example, its going to depend on the specific PLC.

Using a 16 bit example (a more likely one) in some PLC's, 9999+1 would return a BCD 0000 0000 0000 0000 and a status bit would be set in a register to indicate an overflow, and there is an overflow register in at least one PLC I looked at. Now I did the previous math without a calculator, so check it, lol. Anyway, the status bit could be used to do nothing, to do something in the program, to stop the PLC, or a number of other things, depending on the programmer and what he was trying to accomplish. Math overflows are not uncommon in PLCs, it doesn't mean Armegeddon for the PLCs I am familiar with, unless the programmer wants it to.

I have not looked at how all PLCs handle the date function, so I want to be careful here to say that a date is handled the same way as any overflow, we would probably find exceptions, thats why you have to get the Y2K info from the specific vendor. In looking over the Y2K status of a number of PLCs, theres a good bit of variety in Y2K status - some don't use dates, some are compliant, some have leap year flaws that they have always had (some models of Allen-Bradley) and some using a two digit year will return 100 in the year 2000 but keep on running properly IF the application program isn't written in a way that this data won't cause problems - so in many cases, its not just PLC specific, but app specific as well.

That's where assessment and testing comes in. The Y2K assessment/testing should have found ALL Y2K problems, including any rare "maintenance dates."

So basically, I can't see a worry here. If embedded systems went through the rollover when millions used 2000 dates for the first time when some of thes had to have been missed without wiping out society (we hardly noticed), I see no need to get my shorts in a wad over someone, somewhere, might have possibly, programmed in a "maintenance date" that can't handle the year 2000!

You know, I really appreciate the technical discussion here. If we had Paula's programmer, an aeronautical engineer here (like Mikey), a couple of programmers like you guys, and perhaps a few more PLC gurus (I have programmed ladder logic in PLCs, but a few years back, and I haven't done enough to be an "expert", and I haven't programmed dates, they aren't used often by PLCs in the power industry), we could really have an intelligent discussion of subjects such as this, and actually learn something. Maybe something technical, maybe the value in each of us as humans.

I started looking at various PLCs handled the dates and stored data, but not all manuals are real clear about this. I do have some links to PLCs that will let you look for yourselves, just let me know and I will post them. My eyes fogged up after checking out a couple, lol.

Best wishes,

-- FactFinder (david@bzn.com), January 25, 2000.

Factfinder:

The question I am trying to get Cherri to answer is not whether BCD overflow conditions are likely to create problems, but why she said that they cannot create problems, because they don't exist.

Here's her exact statement again: You keep trying to say that getting the date wrong will some way cause an overflow. The machine uses a mathimatical base of two to calculate, we use base ten. What causes an overflow in base ten will not cause an overflow in base two.

Until she explains why she said this when it is clearly incorrect, and how she can claim to be an embedded systems expert while being ignorant of the basics of BCD arithmetic, I can't take anything she says seriously. Can you?

-- Steve Heller (stheller@koyote.com), January 25, 2000.

Steve, Define "embedded system".

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

Cherri, define "up for grabs"

-- George (jvilches@sminter.com.ar), January 26, 2000.

Factfinder, could you please expand about those Allan Bradley PLCs that have "leap year problems that they have always had", and possible impact vis-a-vis the not-so-distant February 29 leap year issue?

Thanks. Take care.

Oh, by the way, Cherri please define "confusion". Better yet, write an essay and post it for us. Take care.

-- George (jvilches@sminter.com.ar), January 26, 2000.

Cherri:

According to the Microsoft Press Computer Dictionary: In hardware, an embedded computer or embedded system is a special-purpose computer that is built into another device.

Now that we have that out of the way, please explain how you can be an expert on embedded systems while claiming that The machine uses a mathimatical base of two to calculate, we use base ten. What causes an overflow in base ten will not cause an overflow in base two. This is clearly incorrect when using BCD arithmetic, for which there are special instructions built into virtually all microprocessors used in embedded systems.

-- Steve Heller (stheller@koyote.com), January 26, 2000.

Italics off again.

-- Steve Heller (stheller@koyote.com), January 26, 2000.

Cherri:
[reposted to fix italics that mark off Cherri's words]

According to the Microsoft Press Computer Dictionary: In hardware, an embedded computer or embedded system is a special-purpose computer that is built into another device.

Now that we have that out of the way, please explain how you can be an expert on embedded systems while claiming that The machine uses a mathimatical base of two to calculate, we use base ten. What causes an overflow in base ten will not cause an overflow in base two. This is clearly incorrect when using BCD arithmetic, for which there are special instructions built into virtually all microprocessors used in embedded systems.

-- Steve Heller (stheller@koyote.com), January 26, 2000.

There is a point here though, we are all human, all subject to not do or say things perfectly. I believe that it isn't quite fair to judge someone on one sentence, on statement. I personally find Cherri to be very knowledgeable of y2k in embedded systems, and I sure can't say that for many.

I would agree with you in general, but in this case, Cherri has repeatedly stated that there can be no overflow problems with the year in an embedded system because these systems use binary arithmetic. I haven't seen her explain why she has made this statement or even retract it, so I have to believe that she still maintains it even though I have proven it false. If she retracts it, then I'll stop mentioning it; if she doesn't, I must assume that she is either stubbornly ignorant or a liar. Neither of these is a commendable quality for someone who claims to be an expert.

-- Steve Heller (stheller@koyote.com), January 26, 2000.

Steve, I cannot grasp the point you are attempting to make. BCD...Yes and your point? 99=1001 1001 you add 0001 and get 9a or 1010. That is what cory H found and fixed and became a "hero" about. If you are adding 99 and 1, buy whatever rules the program is using, so that you have to incriment, it will do as set up to do. Possibly just go back to zero zero, or you get (common on the web) 19100. Are you tring to say?? What? I don't know what BCD is? How it works so I am lying about what I know? What you fail to comprehend is that, wheather BCD or any other form of "showing to people" setup is used, the actual "work" is done by the machine in 1's and 0's. If you use 2's compliment, if you are multiplying, deviding, anything arithmatic, it is done by the machine by square waves of certain voltages going through hardware (intigrated circuits) at different voltages, causing the chip to function "logically", as it is designed to do, to supply a pre-defined result.

So by you saying that BCD is used so it is not done in binary, you are wrong. BCD is a user friendly way of adding, sure, but it is still done in binary. You're being obtuse. You say that if I do not agree with what you say than I am lying about what I know and my abilities. Setting the "rules" as you have done in no way changes the facts of my abilities. Do you understand (beyound the programmers view) how BCD works? Are you attempting to say that an overflow in decimal causes an over flow in bibary? Or is it just a "problem" you have with me? Perhaps it is you lack of knowing exactly what an "instruction" does in a machine, or device that has you confused.

or maybe it just boiles down to an ego problem on your part.

If BCD is set up to be used and is programmed within the realms of logic, the device should handle the "overflow" in the way it was designed to do, as the web-based dates that have come out 19100. The design was wrong, not the chips that the software ran through. Software and programmer error, no system failure or chip failure.

The way you state things, such as "if Cherri cannot answer this she is a lier" shows a deep seated ego problem within your self. You feel the authority to dictate what is what. Sorry chum, you can talk to yourself all you want but don't expect others to follow your rules.

you do not have the authority to negate 30 years of training and experience that I hold, no matter how smart you think you are.

You have a problem with my background? I didn't wwalk into this forum telling everyone what my background was, thinking I was better or smarter than others, you did. I also have no reason or need to "prove myself" to you or anyone else. Too bad you do.

Oh, and the term "embedded system" grew out of people calling every device that was not in a computer and "embedded system". It would be more appropriate to call a device what it is, rather that grouping it to mean everything.

Diferent entities have different discriptions as to whatit is.

embedded system

Hardware and software which forms a component of some larger system and which is expected to function without human intervention.

A typical embedded system consists of a single-board microcomputer with software in ROM, which starts running some special purpose application program as soon as it is turned on and will not stop until it is turned off (if ever).

An embedded system may include some kind of operating system but often it will be simple enough to be written as a single program. It will not usually have any of the normal peripherals such as a keyboard, monitor, serial connections, mass storage, etc. or any kind of user interface software unless these are required by the overall system of which it is a part. Often it must provide real-time response.

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

Steve, I cannot grasp the point you are attempting to make.

Then you are even more obtuse than I would have imagined. Steve, I cannot grasp the point you are attempting to make.

Then you are even more obtuse than I would have imagined, which is saying quite a bit.

Are you attempting to say that an overflow in decimal causes an over flow in bibary?

No, I'm saying that a BCD overflow will occur when you try to add "01" BCD to "99" BCD in a two-digit BCD addition.

Or is it just a "problem" you have with me? Perhaps it is you lack of knowing exactly what an "instruction" does in a machine, or device that has you confused.

I know exactly what an instruction does in a machine. In fact, I've explained it very carefully in my book Who's Afraid of C++?. It is you who are confused. You have stated that:

You keep trying to say that getting the date wrong will some way cause an overflow. The machine uses a mathimatical base of two to calculate, we use base ten. What causes an overflow in base ten will not cause an overflow in base two.

Since BCD arithmetic follows the rules of decimal arithmetic, not the rules of binary arithmetic, your statement that What causes an overflow in base ten will not cause an overflow in base two is irrelevant to the question of whether a BCD operation on BCD data will overflow if you add "01" to "99".

I'll give you one more chance to correct your error. Is it or is it not true that you will get an overflow if you use BCD arithmetic when adding the BCD value "01" to the BCD value "99", using BCD instructions? If you can't answer this question correctly, just admit it and we'll know you're not an expert, but at least not a liar. If you can answer it correctly, please explain your claim that the rules of binary arithmetic have some relevance to BCD overflow.

-- Steve Heller (stheller@koyote.com), January 26, 2000.