My favorite "Myths" about Year 2000
These are a few of the most common things I hear about Y2K that I have
found to be simply not true. These are not counting the really wild
stuff that is out there.
See my Gary North quotes for some of that.
Some of this stuff gets a little technical, so if you are not computer
literate, you might get bored. Sorry.
"In Great Britain, tons of corned beef
was destroyed because of a Y2K bug"
This non-incident occured at Marks & Spencer in England. No corned beef
was destroyed at all. What really happened is that a computer was not
able to read a date properly, and the data had to be entered manually
by a person. Processing of the beef continued as normal.
Thanks to
Hank Hanegraaff to exposing this one. See the
book recommendation for the details.
"A power plant was performing a Y2K
test and the whole plant simply shut down."
There are lots of variations on this one, and I have not yet found
any of them to be true. There is one about Hawaii, Great Britian,
some unnamed nuclear power plant, etc. When you research these, you
will discover that lots of Y2K tests have been performed at power plants,
but none of them resulted in power interruptions. In one case,
two computer screens went blank, but those computers were just used
for data logging. The power continued to be generated. In another incident,
the problems were caused by the
method of testing, not by a Y2K bug. We have proved over and over
by real testing that Y2K bugs do not shut down power plants.
Hank Hanegraaff discusses several of these incidents in
The Millennium Bug Debugged.
"In Minnesota, the government sent a 104
year old woman a letter to enroll in kindergarden because of a
Y2K bug"
It is true that Mary Bander, age 104, received a letter. But it
was not from the government, but rather the St. Stanislaus Kostka Parish
of the Catholic school system. Most importantly, the mistake was a human
error and had nothing to do with Y2K computer problems! Thanks again to
Hank Hanegraaff to exposing this one. See the
book recommendation for the details.
Fake anecdotes like this one really irritate me because they tend
to bring home the Y2K problem and make it bigger than life. This is
a great fear-building story, making people dread the supposed chaos
that is coming with Y2K. Only problem is, it isn't real!
"Y2K problem crash computers"
I have yet to see an example of
a Y2K error that actually crashes a computer. An actual Y2K computer
crash will be very rare. The operating systems people
have fixed their OS Y2K problems - including Windows, Unix, and MVS.
Most Y2K problems - things which make software non-Y2K compliant - cause
the incorrect date to be printed on reports and screens. The more
serious problems cause applications to make the wrong decisions, or to
report an error and quit.
Instead of "Y2K problems crash computers" A more accurate statement
would be "Some Y2K problems cause computer applications to malfunction."
"Every computer/microchip/embedded chip is vulnerable to Y2K failure"
The Y2K failure is only caused by a date dependency in an algorithm.
Even in an embedded chip, there is no vulnerability unless the algorithms
(software or firmware) on that chip have a date dependency.
Put simply,
unless there is some way you can set the date on a device, it is not going
to fail in the year 2000.
Can you set the date on your microwave, copier,
air conditioner, elevator, or automobile?
If the device doesn't even know
about the date, then it cannot have a date dependency.
If it only knows
the date so that it can display it, then only the display has the potential
to fail in the year 2000. The Gartner Group estimates that only about 1
in 100,000 embedded chips will be affected.
A computing device must both keep the date and use it in its function before
it can even be a candidate for the Y2K bug.
For example, a credit-card swipe machine checks the date on your card
before your sale will be approved.
If the expiration date on your card comes before the current date, then you
cannot use the card.
These systems therefore are a candidate for the Y2K
problem because it uses the date as part of its function.
In fact, they did have the Y2K problem and it surfaced 4 years
ago when the first credit cards that expire in 2000 were issued.
That problem has since been fixed.
"No one can know what will happen"
On a global scale,
this is true. The only reason that it is true is that
the worldwide system of computing devices is too large to test.
However, we can take components and test them.
We can know whether or not a single computer will
work come 2000.
We can know whether a certain application is Y2K
compliant.
And we can know about larger systems, such as the data
center at a particular company, a power plant, perhaps even a whole city.
Our ability to know is only limited by our testing ability.
A great example of this is the test of the Unit 4 power plant in
Fort Lauderdale, documented in Appendix A
of my power paper under "FPL progress".
One nice thing about computers is that given the same inputs, they will
always produce the same results. Humans don't have this attribute.
Neither do analog systems.
If you test a system today, and you don't modify it, it will work exactly
the same way tomorrow.
We can know with confidence that successfully
tested systems will work in the year 2000.
"It's already too late to get things fixed"
We still
have months to work on the problem.
Now more than ever before, tools are available to work on the
problem. In the Nov. 16, 1998 issue of Information Week, the
Bureau of Indian Affairs in New Mexico accurately remediated 1.5 million
lines of Cobol code in less than a week using the latest Y2K repair
software. Also, now more than ever, we know more about
the Y2K problem. We have learned which chips, which systems,
which software, which controllers have Y2K problems and how they may
be fixed.
The most difficult part of the problem, finding the date-dependency
bugs, has been completed in many cases.
Companies fall under harsh criticism for not starting soon enough.
But you must understand that 18 months is a generation in computer time.
With the constant flow of new hardware and new software,
it would not make sense to implement Y2K fixes on hardware and software
that will not be in use by the year 2000. Once we crossed
inside of the 18 month span to the millennium rollover, we saw a
huge rise in the Y2K remediation effort, and we are making a lot of
progress.
I think we will make more Y2K progress in 1999 than in all previous years
combined.
"The railroad switches cannot be manually operated"
This is one of my personal favorites, because it is to easy to prove wrong.
I went and check on this myself. I went to an FEC rail system
switch, and there it was - a giant lever used for manual override. I also
went over to a CSX rail system switch and found the same thing.
Click here to see them for yourself
"The CEO of General Motors said that if Y2K were to happen today
that they would not be able to build a car for a year."
The CEO of GM never said this or anything like this. You can read what
really happened in the sermon transcript
Who's in charge here? - just search for General Motors.
And now, a word from our sponsor ...