From time to time I see someone express the idea that Y2K is nothing but a hoax. When you ask these people why they think Y2K is a hoax, they brightly respond that Y2K was cooked up by a bunch of consultants who thought they could pocket millions of dollars in fees for "fixing" something that didn't exist.

Each time I hear this I am awestruck by this combination of ignorance and cynicism that is displayed. Apparently, cynicism is the true mark of someone who is "smart" and "knowing". The real beauty of this scheme is that cynicism is much cheaper and easier to come at than actual knowledge. And cynicism can be acquired in no time flat with hardly any effort. You can pick it up just from watching TV!

I get the same sense of awe when I read other threads that assert knowingly that "they" hatched up Y2K, because "they" want the world population reduced from 6 billion to about 1 billion, or that they wanted an excuse to declare martial law.

It takes an applied force of will to reject a story that has no shred of evidence to back it up, if it appeals to our sense of cynicism. Most especially if the evil-doer in the story is someone unlike ourselves. The powerless love to blame those with power or authority. The well-off love to blame the poor. Everyone loves to blame the foreigner. And so it goes.

The real story of Y2K is far less epical and satisfying than the coming of the anti-christ or the fall of Babylon. It has nothing to do with the shadowy forces of the KGB, the CIA, or the Trilateral Commission. It can't be combatted with an amphibious assault by Navy Seals, or firing of automatic weapons.

In the computer world there is a phrase that is used when the program is asked to do something it was never designed to do: undefined behavior. For example, "Any temperature reading that exceeds 100 degrees centigrade will result in undefined behavior." In layman's terms, this means: "The system will certainly run off the rails. We don't know what happens next."

That is the Y2K bug in a nutshell.

A vast amount of human activity now relies on machines that are computer-controlled. A short list includes: banking, manufacturing, transportation, and energy production. As many of these machines encounter the date 01/01/2000, they will run off the rails.

We don't know what happens next.

-- Brian McLaughlin (brianm@ims.com), November 15, 1999

Answers

I like this essay.

-- Judy (jtruett@gilanet.com), November 15, 1999.

Although you are entirely correct in pointing out that Y2K is real, and is the result of blatant stupidity, not a pre-planned conspiracy, you should not dismiss plans to take advantage of upcoming chaos so easily. After all, the FBI tells us that there are all kinds of militant nuzoid groups that are planning to take advantage of it, even though they clearly did not cause Y2K.

So, a la FBI, perhaps large scale plans to take advantage of Y2K are not so farfetched. Suppose it were known that cities might experience extended power outages due to Y2K, and that conditions for martial law would be ripe. Suppose it were known that the ridiculously overvalued stock market was going to crash, with or without the help of Y2K, but that Y2K could be used as the scapegoat if the so-called "plunge protection team" simply let things fall as they may around early January. Suppose it were feared that Russia might take a "use it or lose it" nuclear stance due to Y2K.

Nobody knows what is going to happen. But that does not prevent people from figuring out how to take advantage of what could happen.

-- King of Spain (madrid@aol.cum), November 15, 1999.

Hoax? Well no, that isn't the word I would use about the Year 2000 problem as a whole. About individual 'news' items, such as the ever present 'sensor in the bottom of the oil well, without which the multi-million well must be scrapped' item, well yes, that is an example of a pure hoax.

And, as a result of the hoax items, Y2K has become a bizzare bogeyman, with many predictions of results that are, to be blunt, impossible.

Self launching nuclear rockets - how? If the key switches are not thrown, power can't be sent to the unclamping and launching mechanism. Just how is an unpowered device supposed to operate itself? And throwing the key switches is a human only operation.

Cars that won't run - why? There is no need for a dating function in any part of a car engine.

I could go on for HOURS. If the myth and impossible is removed from Y2K , a residue of reality remains. But it is much smaller than the hyped up bogey.

-- Paul Davis (davisp1953@yahoo.com), November 15, 1999.

Excellent essay Brain. Ignorance and cynicism, a potent mix. I would also throw out wounded vanity as cause for fantastic stories and heated emotions. Without these we are basically left with, we couldn't have been that stupid could we have? Tough question.

-- PD (PaulDMaher@att.worldnet.com), November 15, 1999.

Yeah, I've seen serious claims that nobody ever walked on the moon, the entire Apollo program was a fabrication by the government.

But my sense from talking to people who aren't paying much attention to y2k, is that the bugs may have been real before we fixed them, but even if we missed a few, we'll just deal with them like we always do. Not a hoax, but no big deal. Any 'hoax' aspect lies in the wild scenarios dreamed up by those who combine imagination and fear to create the preposterous.

This is hard to deal with. Any argument that it may well end up being just a bit worse than just something you sometimes see on TV requires lots of documentation nobody wants to waste their time listening to. I've give up trying.

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

Brian --

Great essay. I will, however, take exception, (as a long-time programmer), to the idea of 'undefined behavior'. When in the course of writing a program, a case statement, nested if's, or other construct which compares or evaluates conditions, an undefined condition occurs, (that is, a condition which exceeds the limits defined for the operation), the behaviour is most certainly *NOT* undefined! The behaviour, assuming someone responsible, who actually has a clue about programming wrote it, is very well defined. It is called a 'shutdown'. (For the laymen out there, that translates as: 'Stop doing whatever it is you are doing, because whatever it is, it isn't what you are *supposed* to be doing, or at least we aren't *sure* that it is. So stop it. Now!)

This is one of the big reasons the current situation worries me. I fail to believe that there were enough programmers out there clueless enough to have left 'undefined' conditions as 'continues' to make this the 'non-event' so many seem to be anticipating.

Paul Davis --

No, there isn't any reason why a car should need a date. This doesn't mean that there aren't cars out there with chips which have exactly this type of behaviour. In the industry, it is called "feeping creaturism". This is a 'spoonerism' for 'creeping featurism', or the tendency of a system to have a whole bunch of stuff added on that is not strictly necessary to the functional operation of the device, (or, in some cases, not even remotely connected to the operation). It tends to be driven by the marketing department on the basis of 'because we can', although I have seen engineers overcome with the power inherent in stuff that could be called 'kewwll', (I think that is the correct spelling).

This is one of the reasons that I distrust some of the surveys and percentages, particularly for embedded systems, where, in many cases, the original source code is one with the passenger pigeons. The standard methodology is 'functional analysis'. This is an effort to determine whether or not, for a given system, there are any functions which require a date, and whether or not, given that there are, if any require arithmetic or boolean calculations. This is fine, as far as it goes, but doesn't give any idea of whether or not the thing got loaded up with a bunch of 'features' (in this case defined as completely useless crap that doesn't actually prohibit operation of the device under normal conditionsl).

This is a *whole* lot more prevalent than is commonly supposed outside of the engineering community, although you needn't look very far to see examples of it.

-- just another (another@engineer.com), November 15, 1999.

Thanks, just another. Paul, do you base your sense of what's a hoax on research and knowledge or that famous gut instinct that convinces most people I know that everything will be all right? In other words, I read all the oil material that was posted here, recently, and from what I read there is a high likelihood that there are wells with embeddeds deep down there. One person familiar with the wells said no, but admitted he did not know the type of facility that DD was talking about. There was confirmation that those wells have embedded chips.

Good essay, Brian.

-- Mara (MaraWayne@aol.com), November 15, 1999.

Another Engineer,

As another long time programmer I can only assume that your programming has not been on IBM mainframes. In that environment "Undefined" is used constantly. For example, in PL/I the result of divivion by zero is officially "undefined". You can use a PL/I "on unit" to cause whatever behaviour you want, but in the abscence of such an on unit and if the ZERODIVIDE condition has been disabled then anything might happen. Just the sort of error that might occur if something was being divided by the 2 digit variable YY!

Actually, in this case everybody knows what will happen, but by defining the results as undefined IBM can change this behaviour if they want. Your programs should not take advantage of undefined behaviour because it might change without notice.

RonD

-- Ron Davis (rdavis@ozemail.com.au), November 15, 1999.

Mara: I have tried and tried to get the people responsible for these hoaxes to answer one little question: "What is the mfr name, part number and serial number of these devices?". You can't get them to answer that question.

And, I have never heard of an engineer designing a component that CAN'T be replaced, that is critical to the operation of a piece of equipment that costs millions. Such a person would have a job just as long as that first component did not fail. About one minute later they would be blackballed all over the industry.

And failures there would be in plenty - conditions at the bottom of any deep oil well can best be described as a pressure cooker, at maximum pressure and heat, filled with a mixture of salt water, light oil, heavy oil, benzine, gasoline, and rock dust. High pressure and high heat in a very nasty corrosive environment. Just what would you build such a sensor from? And how do you get the data back - a wire that can support its own length for 30,000 feet is not a minor item you can pick up at the hardware store. Not to mention the weight of the sensor. Anything down there must be logically be temporary, and I can't find anything listed as a permenant sensor with any of the oil field company catalogs on the web. Incidentally, my father's farm has several oil wells on the property, and there aren't any sort of sensing/recording equipments attached to them. So unless someone can provide something like a part number, I'll say there is nothing to it, as a result of both logic and research.

As for cars and other 'unseen date rumors', the thing is that I don't believe in MAGIC! There is no way to set a date on a car computer, just ask your mechanic.

And, you see, most don't seem to take into account, that RTC chips are not even Year 100 compliant! If the chip doesn't get a default startup date from something, it just starts at 0. So it has to count out a century before it can possibly have trouble. How many cars last a century? How many car computers were around even 20 years ago? The matter is moot. Since there is no way to set a date on a car computer, the date doesn't matter, as with every system reset (battery drain or computer failure) it will go to zero. And I don't think anyone has actually put an RTC in a car computer anyway.

-- Paul Davis (davisp1953@yahoo.com), November 15, 1999.

Down in the hole embedded systems for oil wells is no hoax. I don't know the technical name for those things that go in well, guys in the machine shop just called them "logs", and those parts definitely had hand pockets machined into them for on board computers.

-- Ocotillo (peeling@out.===), November 16, 1999.

God Bless the United States of America





-- the Virginian (1@1.com), November 16, 1999.

The Virginian --

COOL FLAG!

RonD --

Well, you called that right. I haven't programmed on a 'Brand X' in right at 30 years. However, are you trying to tell me that you do case statements, or ifs and let undefined results do whatever they want to???? Yes, the *CONDITION* is undefined, but the *BEHAVIOUR* damn well better be defined. And it is probably, unless it was overlooked, defined as 'STOP! Print out, display, or otherwise make known to the world at large that the unspeakable has occurred and an unforeseen error has occurred. And stop doing ANYTHING if you are running a process.' Maybe you big iron guys can let one run away, but the real-time embedded better not be doing so! And even in your case, you probably shouldn't.

Paul --

You want a part number? Okay, I'll give you a part number. MC68HC11. How's that? This is a microcontroller chip, widely used, popular, and it has everything the growing programmer needs to do just about any sort of real-time embedded process control. Real time clock, built right in. Random Access Memory (RAM, for the computer-literate), I/O control ports right there on the chip, and, of course, since these take up a lot of room on the pins, pins being a natural limiting factor in these sorts of things, the Read Only Memory (ROM, for the computer-literate) is ALSO right there on the chip. That way, you don't use up a lot of pins maximizing the address bus. So you can get more of those neat I/O pins. Which are, after all, the purpose of the exercise.

And what, pray tell is IN that ROM??? Why, the control program. Written by the Original Equipment Manufacturer, or 'OEM' as those in the business like to call it. And what does this control program do? WHO KNOWS! The guys who wrote it do. And 'maintainance' is difficult, to say the least, since these things have their program in silicon, not as little magnetic blips on a disk or a tape. So there probably isn't a big maintainance programming department keeping tabs on it. In fact, in a lot of cases, the original source is gone. So are the original programmers. And the documentation wasn't typically all that great to begin with. Usually, a VERY low priority.

Now, having said all that, do I have any specific pieces of equipment in mind. Sure do. Will I give the name of an OEM? Not a chance in hell, buddy. Because if I do, and they get wind of it, my little butt goes right straight to court. Non-disclosure agreement, yellow dog contract and all.

The "manufacturer" you all prattle about, in this case is Motorola, a Fortune 500 company. Do they have any responsibility? Nope. From their point of view, the 'program' is typically a binary bit pattern which is burned into the actual chip itself. They neither know, nor care. (In fact, they probably secretly hope you screwed it up, since the 'fix' is to process another batch of chips!)

Are there any of these little bundles of joy in any cars? Well, if there aren't, it is sure gonna come as a REAL big surprise to a good freind of mine that Delco was paying him big bucks for the last 4 years to program chips that never went into any cars! I suppose its possible. Some of these big companies never let their left hands know what the little finger on it is doing, much less the right hand. Shoot, thats basically one of the reasons we're in this mess to begin with.

-- just another (another@engineer.com), November 16, 1999.

"feeping creaturism". This is a 'spoonerism' for 'creeping featurism', or the tendency of a system to have a whole bunch of stuff added on that is not strictly necessary to the functional operation of the device, (or, in some cases, not even remotely connected to the operation). It tends to be driven by the marketing department on the basis of 'because we can', although I have seen engineers overcome with the power inherent in stuff that could be called 'kewwll', (I think thatis the correct spelling).

Yep, indeed...Windoze 95 and 98 are exemplars of this phenomenon...and add "really kewl features that inhibit the functioning of said device, (software, etc.)"

-- Donna (moment@pacbell.net), November 16, 1999.

Donna -- Right. Actually, in some quarters, the definition of a 'feature' is: "A bug that does not totally inhibit operation of the device, but may, in fact, alter correct operation beyond the ken of anyone involved."

-- just another (another@engineer.com), November 16, 1999.

Brian & JustAnother,

Excellent posts. Thanks.

-- GoldReal (GoldReal@aol.com), November 16, 1999.

Quick thought: It's possible to believe that men have walked on the moon, but that the NASA photographs are fakes. They're not exclusive.

Similarly, there's a lot of patent untruths being touted about Y2K. But that doesn't mean it's NOT an immense problem.

-- Colin MacDonald (roborogerborg@yahoo.com), November 16, 1999.

I suppose I should have listed as another myth, the idea that 'pollies' don't expect anything to give any trouble. Total myth.

Anyway, logging takes place during drilling, not pumping. Working oil wells are pumped, not drilled.

Yes, you can burn a noncompliant program into an otherwise compliant device. That is hardly news, and is the reason an awful lot of money just got spent chasing embedded control systems all over creation. Considering the number of places that have run date runup tests, I don't see a lot of trouble coming from that.

Only sensor I can even think of that would survive any length of time at the bottom of an oil well would be a strain gauge. They don't have chips.

About car devices, once again, if you can't set the date, then the date doesn't matter. And if it doesn't matter, then it could fail tomorrow, or not fail for 100 years. In 46 days you are going to KNOW whether or not the car mfrs have told the truth about car computers. But there isn't any function for setting dates in the diagnostic equipment, and everyone denies there is any sort of date setting required at the factory. So how is it supposed to know when the rollover occurs? Magic? Don't know about anyone else, but hand waving around the nonrequirement for a date setting doesn't cut it for me.

And it would be pretty obvious if it was required. Every time you had a car go without a battery for a few days (as in a wreck where the battery had to be disconnected for fire safety) it would come up blinking lights and ASKING FOR THE CORRECT DATE when the power came back on! How would you hide that?

-- Paul Davis (davisp1953@yahoo.com), November 16, 1999.

Paul --

Right you are. That is why there has been a lot of money spent on the problem. (BTW, this is probably one of the reasons why you can safely assume that Y2K is not a hoax. There were problems found in the doing of this.)

This was exactly my point. And, if I read it correctly, the point of the Dale Way essay. (Several threads below. Way's critique of Yourdon's End Game Essay.) The *hardware* usually doesn't *CARE* about the date. End of story. The *SOFTWARE*, on the other hand, (or firmware, if you are a stickler for the definitions), *MAY* and often *DOES* care about the date.

As for cars, again, I stated it above, I'll state it again. (Using words of ONLY one syllable, hoping you can actually understand them.) I know of *NO*, *NONE*, *NADA* cars which need a date. (There. All one syllable words. Longest one is 5 letters. Clear enough.) You stated that there aren't any. You asked for part numbers. Okay, as for the part number, you got one. A manufacturer, okay, you got one of them. Even an OEM. Pick one of the big three automakers. I believe they all use that part in one or another application.

Do they, in fact, have date dependencies? I don't know. Never worked on an automotive application. My experience is elsewhere. Information at 'second-hand'. Again, I wouldn't think so. But I *don't* know, and at least one of the Big Three has given out numbers so unbelievably outrageous (2 billion lines of code remediated in 18 months), that I wonder at *ANY* statement they make regarding this.

(Oh, and by the way, your argument which "proves" that there aren't any applications with such a requirement? You know the one that says,

"About car devices, once again, if you can't set the date, then the date doesn't matter."

The one where you talk about how there would be some flashing numbers demanding a date be entered?? Yeah, that argument.

I just went down and took a look at my vehicle. Son of a gun.. I have the ONLY vehicle in the world that has a bunch of flashing numbers that look like, GASP... it is, it is a *TIME*. Gee, how did I get to be so unlucky. The only car.... what's that? You say yours has those numbers too? And you? You too? What is this, some kind of conspiracy? Only the 'doomers' (non-pollies) have vehicles with these flashing numbers that came from a, GASP, *clock chip*? They are trying to rot our brains. Get out the tinfoil hats. Shoot, get out the tinfoil *BODY ARMOR*!

(specious argument sarcasm mode OFF)

Do I know if they are doing anything with this besides telling us the time? No. And, as I stated before, functional analysis would suggest that the answer would be no. But, functional analysis is suspect, for the reasons I gave above, and I cannot seriously believe that *ANYBODY* in the engineering profession has never encountered the phenomenon.

(An afterthought, and purely parenthetical. As for functions which *might* use a date, here is a thought. You know that nifty little light on most of the cars and trucks built since, I think, about 1994, that says 'check engine'? Or the one that says 'service engine soon'?

While it wouldn't be *my* choice to trigger those on a 'date', I, being practical and sane, would *much* rather trigger them on something rational, like, say, mileage, I *can* envision them being triggered that way. In fact, I can even make a case that you could combine date, mileage, average speed, and mean speed to come up with a truly *USEFUL* method of triggering these lights.

This suggests that even in the absence of 'feeping creaturism', functional analysis may be suspect in this case. And once we get there, it really becomes a question of how that 'clock' works and gets set and reset. And an interesting point comes to mind, with regard to that. Although there are several ways in which such a clock can be initialized, one of them is through a 'machine-machine interface'. As opposed to the infamous 'mmi' or 'man-machine interface'. In this case, the clock gets set based on input from some other machine. For those with those nifty on board nav, trip designer, etc software like GM's OnStar (tm) this probably comes from your friendly neighborhood satellite feed. (Always assuming that you can envision a satellite as a part of your 'neighborhood ;-)). So you have zero (0) control over what that setting is. Somebody, somewhere else, has this control. Comforting thought, isn't it?

At any rate, this is something, simply, to ponder. Again, I'll point out that I haven't a *clue* whether or not the cars out on the road have any problems of this nature. My experience with marketing departments leads me to believe that the possibility exists. Nothing I have seen, to date, precludes this, including your 'hand-waving' and screams of 'magic'. )

-- just another (another@engineer.com), November 16, 1999.