Can someone explain WHY an incorrect date field screws up computer?

greenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread

I'm not a polly, troll, etc. I am preparing, but i'd like an explanation please. What goes on internally in a computer that causes an incorrect date field to make a computer go haywire or shut down? I can see why you might get charged for 100 years of insurance or be 100 years old, but why and under what circumstances would the computer go bonkers or shut down? What is the liklihood of this? Thank you very much.

-- I Am (Computer@Illiterate.com), October 13, 1999

Answers

I am:

This depends entirely on the details of the code. There might be a hundred ways to write a date handling routine wrong, and these might produce a hundred different symptoms. That's just the nature of programming -- if someone misunderstands what you say, you can't predict what they *thought* you said, so you can't predict how they'll react.

You should also be aware that some (all too many!) types of programming errors can snowball inside the computer. If one routine is wrong, other routines relying on it will be wrong. So the routines that rely on *them* will be wrong, etc. Bugs often show up in someplace far different than they happened, with symptoms not at all obvious to track back to the actual coding or logic error.

Debugging is not a mechanistic process, it's an art.

-- Flint (flintc@mindspring.com), October 13, 1999.


I am --

Flint has it about right. However, the explanation he gives may not satisfy, so I'll try and give a concrete example.

This one is from my days as an embedded systems programmer. An embedded system is typically either a microprocessor or a microcontroller. The difference being that a microprocessor has a full instruction set and typically reads a program from a device called a 'prom' or 'eprom', these being 'Programmable Read Only Memory' and 'Electrically Programmable Read Only Memory', which are devices that can store a program for a processor, and which can be written to (that is the 'programmable' part), while a controller has it's memory right there on the chip, (which saves a LOT of room on a circuit board!), and is not programmable in the sense of most computers after it has been manufactured, as the program is 'burned' into the chips Read Only Memory (ROM). (Note the non-appearance of the word 'programmable'.)

The case in point is a controller routine written in the mid-1980's which was a classic 'control loop' style program. This particular one controlled some fairly expensive (and somewhat dangerous in the wrong circumstances, such as uncontrolled startup) equipment. So there were various things that were tested prior to the control loop being allowed to start running. These are known as 'sanity checks'. One of them, in fact, if memory serves, the third thing tested, was a 'date verification routine'. Guess what one of it's tests was? That's right. It checked to see that the computed year was valid. And it didn't recognize dates that didn't begin with a '19' in the year field. Of course it was stupid, but the stinking chips only had a life expectancy of 5 years, so who knew. But there is a simple example of the sort of thing that can happen.

Hope this explanation helps.

-- just another (another@engineer.com), October 13, 1999.


In the cases is which a date error would lead a computer to shut something down, that something would probably not be the computer itself, but something else that the computer would be controlling. In some process control applications, the computer is programmed to shut down the process being controlled when and if the data does not pass any of various plausibility checks.

On the other hand, many date errors will simply lead to incorrect output such as you suggested. Some other kinds of incorrect output might include: deleting data because they appear to be ancient (this can be a whopper of a problem), sorting data in incorrect sequence when the sort key includes dates (out of sequence data can lead to many kinds of incorrect output), the Kraft Foods example of discarding new ingredients because their expiration dates appeared already to have expired, incorrect calculation of interest, incorrect asssessment of late charges, etc.

Jerry

-- Jerry B (skeptic76@eerols.com), October 13, 1999.


One of the main problems being encountered in the remediation is the lack of sufficient time to accomplish the changes to the code. This includes

In a large system or system of systems, this is a daunting task, and may contain many, many more subprocesses, such as

etc, etc, etc. And this assumes programmers are not heading for safe havens or taking sick leave to make preps.

The pollies argue: But we do this stuff all the time. Yes we do. But not on this scale, not everywhere in the whole world in every company in every industry in every system at once, and not with a fixed schedule.

One of the main arguments in the pessimist's camp is that the software industry has a rotten record of allocating enough time to complete a task on a immovable deadline. In fact, only around 20% by some estimates are able to accomplish this. And we're not even talking about dealing with residual errors, which presumable could be fixed on failure, assuming all shit hasn't broken loose in other sectors of industry and society. So, worst case, only 20% will be successful. But, we doomers are generous and guesstimate that maybe 80% will be successful.

So you tell me: Can an industry, such as banking, continue to function if only 80% of its systems (just the mission critical ones mind your) are working properly? Keep in mind I've just barely scratched the surface of the "Y2K Problem", and am not addressing any other factors that may exacerbate the situation, such as a market collapse, panic, terrorism, shortages, dominoe effect, wrong decisions by government, natural disaster, and so on.

-- a (a@a.a), October 13, 1999.


Y2K essentially causes three types of problems in computer systems. First, it causes dates to be compared incorrectly. A human knows that a date 991231 is less than 000101, but a computer determines that 991231 is greater than 101. Second, it causes dates to sort incorrectly. This is similar to the first problem, but it is on a massive scale because large databases have files containing millions of records. Third, it results in incorrect date arithmetic, which is the means that computers use to determine the elapsed days between two dates. An example using years instead of days is that 99 - 60 equals 39, but 00 - 60 equals -60.

-- Mr. Adequate (mr@adequate.com), October 14, 1999.


Ah'm PROUD of all of ya's!!

NANNY DELETER

-- Nah, y'all know already (Z@z.z), October 14, 1999.


'a':

Aha, I begin to get some insight into your perspective. You address the organizational *process* of creating software, which is indeed complicated and involves a lot of people doing a lot of different tasks, all of which must be coordinated. Most of these apply for any software project, whether remediation or new development. And I agree these tasks and subtasks and subsubtasks are all necessary, and must all be properly coordinated. When you start to list them all out, it looks daunting to the point of impossibility.

Yet software is created, at a rate which makes y2k a threat in the first place. It's hardly impossible to do all these things. Yes, we must wrestle with non-stellar management, impossible deadlines, mutually exclusive requirements, moving targets and the like. And somehow despite all of this we've developed trillions of lines of working code.

On a remediation project, many of the things you list are already taken care of. For example, we don't need to decide what language to use; we don't need to purchase and learn the tools; the functional specification is vastly simplified -- the 'final product' should do exactly what the current product does, etc. We can and do take advantage of this, and by now the vast majority of remediation projects give every indication of having been adequate (though of course never perfect).

Curiously, I have yet to see a post from you that doesn't contain at least one attack against someone, either direct (usually) or implied. No other poster here has such a consistently belligerant, antagonistic attitude. You emphasize the management aspect of remediation, yet seem to harbor this same antagonism towards management. Is it any wonder you can't seem to imagine a well-run remediation project?

-- Flint (flintc@mindspring.com), October 14, 1999.


Flint, where did I say choose a language? Where did I say go through the rigors of the requirements, specifications and design process? As for tools - just so you'll know next time, people are using new tools to analyze the trillions of lines of source code. Otherwise remediation would be impossible. Furthermore, I could use a barrage of additional arguments like software had to be rewritten from scratch because of missing source code, hardware incompatibilities, outdated software environment, etc etc etc. but I was trying to keep it simple.

As usual, you tend to simplify a description of a process that has already been simplified. And of course you use the standard polly arguments like "there's 119 companies on deJagers site that look swell! See I told you we were almost done"

Then you say, "I have yet to see a post from you that doesn't contain at least one attack against someone" and you had just finished reading one. What's your problem? And you have the audacity to call me belligerant? Just days after you said I "have Milne's dick in my mouth"?

You're a damn hypocrite Flint.

-- a (a@a.a), October 14, 1999.


'a':

I agree the process is very complex. I said that already. I didn't reference de Jager's list, which I consider moot. I've said repeatedly that I don't expect anyone to finish all the steps of any significant remediation effort. As for hypocrisy, you need to consult a dictionary. I made an accurate observation (which you reiterated above). Making accurate observations isn't hypocritical, regardless of who makes them.

In any case, I'm not trying to argue with you here -- I agree with everything you said about the process. It's true. There is some debate over whether a significant remediation effort should be regarded as one large task (like a major new development) or a lot of smaller tasks, related to one another only in the general sense that they are all repair projects. Finished systems are being returned to production in phases, so it's not all-or-nothing. We have ample evidence that organizations have prioritized their systems, and have returned the most important systems to production. So if they don't finish on time (most won't), it will be the least important systems that remain to be completed.

Finally, as Hoffmeister has pointed out so cogently, this process doesn't apply to the roughly 25% of organizations that are implementing entirely new systems. That IS much more of an all-or- nothing, the scope of problems is MUCH wider, and the problems are being (or have already been) encountered. Almost all of the computer glitch reports posted on this forum have resulted from these new implementations. I find it difficult to accept Hoffmeister's contention that the current global error *rate* is an order of magnitude greater today than it will be after rollover, but without question many y2k problems have been shifted backward in time due to both remediated systems returned to production and the main pains of new implementations. It simply cannot be (honestly) denied that a sizeable percentage of the Time Bomb has already gone off.

To summarize: It's one thing to claim (IMO accurately) that the process is slow, error-prone and complex. It's quite another to argue that THEREFORE it isn't being accomplished to any noteworthy degree. That's simply false. Hard is not the same as impossible. We haven't spent hundreds of billions just wringing our hands and bemoaning the sheer size of the task. No, we haven't reached the finish line and probably never will. At best, we have reduced the problem to manageable levels, in most cases. There *will* be horror stories.

-- Flint (flintc@mindspring.com), October 14, 1999.


Flint said THAT? Damn, I always miss the jealousy responses.

-- Vic (Rdrunner@internetwork.net), October 14, 1999.


Flint said:

It's quite another to argue that THEREFORE it isn't being accomplished to any noteworthy degree. That's simply false.

You're not auguing with me Flint, you're arguing with 30 years of software engineering metrics. Carry on.

-- a (a@a.a), October 14, 1999.


'a':

Yes, we have metrics indicating that very large development projects are nearly always late or cancelled. You've pointed out many of the reasons for this.

Yet we face the y2k issues we do because so many large systems have in fact been implemented, not because they failed because they were too hard. Whether we (in aggregate) gave ourselves enough time to reduce the problem to a manageable level remains to be seen. And I think it's worthwhile to make the effort to distinguish y2k problems from problems we'd have encountered anyway.

One reason I mentioned that large remediation efforts can be viewed as many small, often unrelated projects was that I had my eye on those very metrics. Historically, the smaller the project the better the success rate (a logarithmic relationship). A lot depends on how the entire effort is organized and managed, and a lot depends on the quality of our tools.

IMO, the only valid way to qualify and quantify the actual success rate is to examine the actual results we've achieved. And if all reports of positive results are rejected on principle, then such an examination is rendered impossible, leaving us to base our conclusions on pure faith. You have fallen into circular reasoning when you tune out the real world. You are saying we're hosed, therefore all positive information is incorrect, therefore there is no positive information, therefore we're hosed.

Although I've noticed that you've been laying the groundwork to claim that y2k must have somehow been an indirect, or underlying, or trigger mechanism for whatever you decide is a Bad Thing, even if the chain of causality cannot possibly be traced. This is an admirable hedge position, since Bad Things always happen, especially if *you* get to define them. But I somehow question the rigor and integrity of this approach.

-- Flint (flintc@mindspring.com), October 14, 1999.


I am,

Please ignore the ramblings between Flint and whoever.

Simple explanation - computers often rely on time to tell them what to do next. The simplest way to structure that is to have a timing system (clock) within the software and/or hardware. Many of these "clocks" use only 2 digits. This was done to save money because once upon a time storing 4 digits was much more expensive than 2.

The computers don't know that 00 means the year after 99. They will think it means 1900. This will result in negative date calculations. Computers don't do well when their logic is screwd up. Lets face it - logic is all they have. So the computers will be confused which is a bad thing for those of us who have become dependant on them.

There are tiny computers inside billions and billions of machines. Everything from oil wells to x-ray machines. Many of these tiny computers are non-compliant. Nobody knows for sure which ones. There is no way to replace them all.

This is a BIG problem and could well result in making your life exceedingly different from they way it is now.

Please keep asking questions. Thats why this forum exists.

-- R (riversoma@aol.com), October 14, 1999.


R:

Your summary is disingenuous. You wrote:

"There are tiny computers inside billions and billions of machines. Everything from oil wells to x-ray machines. Many of these tiny computers are non-compliant. Nobody knows for sure which ones. There is no way to replace them all."

These statements are at best an exercise in half-truths. True there are billions of microcontrollers out there. "Many", upon investigation, has turned out to be a couple of orders of magnitude fewer than was originally feared. And there has been a *lot* of investigation. And of these, "non-compliant" is both true and non- threatening. In the large majority of cases found of actual noncompliance, the error itself didn't interfere in any way with the proper function of the device. We've been told that if NONE of the noncompliant devices in the electrical generating and distribution had been remediated, we'd still have power. And so far, nobody with detailed knowledge has said otherwise to my knowledge.

As for "nobody is sure which ones", this is only very slightly true. Before the investigations were performed, this was very true, but again that investigation has been fairly comprehensive. And although it's true that they all cannot and will not be replaced, most of those few that would interfere with functionality have been replaced. Those hundreds of billions of dollars weren't spent doing nothing.

It appears certain that there will be problems in this area, and preparations against them are still highly prudent. But we now know enough to realize that our infrastructure won't collapse around us.

-- Flint (flintc@mindspring.com), October 14, 1999.


Flint, you two-faced rat, you should know a lot about being disingenuous, seeing how you twist logic to fit your views on Y2K and other subjects. You're a hypocrite too. You preach complacency non- stop, when you yourself are prepared to the max. And you are a psychic! You make fearless predictions about what is going to happen in the year 2000, under a fake name too, so you can just disappear if you are wrong in these predictions. I've been reading your postings at this forum for over a year now and I wish I had a dollar for everytime you made a total jackass of yourself, I could retire right now! Your credibility factor is zero, zilch, nada. You always try to prove how clever and smart you are, but buddy, you are not nearly as clever or as smart as you think you are.

-- Ohio Bob (ohiobob@buckeyestate.com), October 15, 1999.


Amen.


-- Sysman (y2kboard@yahoo.com), October 15, 1999.


Ohio Bob:

My name and address are both real, not fake. If there are big problems, I'll admit I'm wrong. Yes, I'm prepared for them and I've always said preparation is wise.

I've been trying to ferret out what has actually been done and what hasn't. Investigations into embedded systems has shown that problem to be far smaller than feared. This is a fact. There are *still* embedded problems, to be sure. It's not like they don't exist.

Unlike you, I don't see a binary world where everything is either great or terrible. You seem to have made up your mind that everything is terrible, and you tune out or reject anything that says otherwise. Often, this requires highly artificial special pleading, persuasive only to a fellow believer. Nothing is more reasonable than a shared prejudice.

And I am deeply disturbed by the Infoliant findings just like everyone else. I'm well aware that everyone is "on track" right up to the deadline, at which time they're way behind. I see this happening with y2k as well. So I absolutely expect y2k to be messy.

But from my perspective, you have simplified the situation beyond the point of distortion. If *you* aren't able to see that out of ALL the Senate testimony, those here chose to select the single worst piece of testimony from International Monitoring and post it on three different threads, while ignoring ALL the rest of the testimony, then there's nothing I can tell you. If anyone who looks at all the testimony and tries to draw a balanced picture is a rat, while those who select the single worst statement and start chanting it are your heroes, then so be it.

-- Flint (flintc@mindspring.com), October 15, 1999.


Flint, nice comeback to my post. But, you're still a rat. And I don't have a negative view on everything, just your distortions.

-- Ohio Bob (ohiobob@buckeyestate.com), October 15, 1999.

Ohio Bob:

You sound kind of like Plato, who regarded reality as a distortion of ideal forms. In your case, the ideal form is the worst case y2k scenario, and reality where everything is all over the map is the distortion. I don't agree with that philosophy, but it does have a history.

-- Flint (flintc@mindspring.com), October 15, 1999.


Moderation questions? read the FAQ