(This editorial was published originally on AVweb - The Internet's Aviation Magazine and News Service and is republished here by permission. Access to AVweb requires registration, so a simple link would not work. © 1998 Michael Busch - All rights reserved.)
Okay, folks. This nonsense has gone far enough.
It's one thing when a handful of self-appointed Y2K consultants and gurus hang out their shingles and their web sites to take advantage of the gullible and panic-prone. Or when a few thousand survivalist whackos announce plans to spend their 1999 Christmas vacations fleeing from civilization and holing up in the desert with stockpiles of cash, food and ammunition. This is all in the grand American tradition of laissez-faire capitalism and individual freedom.
But, when Newsweek publishes dire predictions of financial institutions collapsing, planes falling out of the sky, elevators stopping, and cars not starting as their embedded microchips go bezerk on January 1st, 2000, and when Mike Wallace and Dan Rather start using the power of network television to persuade the populace that Y2K will bring TEOTWAWKI (the end of the world as we know it), I start getting alarmed.
And when prophet-of-doom Dr. Edward Yardeni, chief economist of Deutsche Morgan Grenfell, estimates the probability of a deep global recession in 2000-2001 as a result of Y2K problems at 70%, I start to worry that such high-profile doomsday predictions may freak out investors enough to become a self-fulfilling prophecy and cause a whole lot more damage than anything that the so-called "millenium bug" itself could wreak.
Which, as I hope to demonstrate to you, isn't all that much.
Before co-founding AVweb in 1995, I had a 30-year career in the computer software business. I designed, developed and managed the development of operating systems, networking, and financial applications for Fortune 500 companies. I spent three years designing and developing credit card authorization systems for Visa International. In short, I've been on the inside of this Y2K stuff, and it sure looks to me like the problem is being vastly overblown. Here's why.
The high prophets of Y2K and their bamboozled dupes in the mass media paint a picture of global computer meltdown in the wee hours of January 1, 2000. The biggest flaw in this millenium apocalypse scenario is the fact that dates in the year 2000 are nothing new to our computer systems. They've been dealing with such dates for years.
Financial systems have been coping with 2000-series dates since the 1970s in the processing of fixed obligations (such as government and corporate bonds) with 30-year maturities. Medical and insurance systems have had to deal with pre-1900 birthdates, which are just as vulnerable to the "two-digit rollover problem" as post-1999 dates are. When I was doing software work for Visa International between 1993 and 1995, Y2K compliance was the law of the land because everyone knew that credit card expiration dates in the year 2000 would be upon us years before Y2K itself.
Indeed, there have already been a handful of high-profile embarrassments resulting from Y2K-related bugs, mostly having to do with time-interval calculations that involve subtracting one date from another. In late 1997, a computer system at the Marks & Spencer department store in London ordered tons of perfectly good food destroyed in the process of doing a long-term forecast when an application program interpreted some expiration dates as 1902 instead of 2002. Instead of four more years of shelf life, the program calculated that this food was 96 years old and ordered it destroyed. A similar problem happened to a U.S. manufacturer of freeze-dried food.
The point is that Y2K-related software problems are not going to emerge all at once on New Years Day. The ambiguity of a two-digit year doesn't kick in suddenly with one tick of the clock, as the doomsayers would have you believe. Most of these problems have already shown their ugly faces, and been fixed or worked around. More will do so as Y2K approaches. They'll be annoying, cause embarrassment, and maybe even cause some folks to get fired. But, "the world as we know it" will hardly notice.
Let's put an end to this "embedded microchip" scare once in for all. It's certainly true that an increasing number of appliances and vehicles are controlled by embedded microprocessors. But your coffee maker, microwave, dishwasher, television and automobile simply don't care what day it is, much less what year it is. (Think about it. Why would they care?)
The only common household appliance that cares about dates is your VCR. If you have an old one, it might not handle programmed recording correctly after Y2K. If you're really worried about this, just set your VCR clock to January 31, 1999 and then watch what happens. Even if you're affected by this problem, you can probably survive somehow. Besides, that old VCR probably needed to be replaced anyway.
Hardly any industrial microcontrollers care about the date, either. Y2K doomsayers paint a vivid picture of elevators grinding to a halt (or going bezerk) at the stroke of midnight on January 1, 2000, but a spokesman for Otis Elevator says this is absolute hogwash.
Most software systems in current use -- including virtually all PCs and workstations, network servers, and the machines that route and switch data over the backbone of the global Internet -- won't be affected by Y2K because they handle times and dates in a fashion that simply doesn't care what year it is.
Take Unix, for example, which is the operating system that runs most Internet servers and routers as well as most engineering workstations. Unix stores dates and times as a 32-bit signed integer that denotes the number of seconds that have elapsed since midnight UTC on January 1, 1970. Since 32 bits is sufficient to encode integers from -2,147,483,648 to +2,147,483,647, Unix dates will not run into a rollover problem until January 18, 2037 (which is 2,147,483,647 seconds after January 1, 1970). January 1, 2000, is a totally uninteresting date so far as Unix is concerned.
Other modern operating systems use similar schemes. If you're running DOS, Windows 3.1, or Windows 95, the operating system date encoding will work fine until the year 2018 (at which point hopefully nobody will still be running these operating systems). Windows 98 and Windows NT can deal with 21st century dates without heartburn.
If you're running an old 68000-based Macintosh, your dates won't roll over until the year 2040. New PowerPC-based Macs have dates valid through the year 29,940 AD, which should certainly be ample for anything you have in mind (unless perhaps you're a cosmologist).
The Global Positioning System is subject to a more obscure problem that is caused by data format that is transmitted by the satellites. Time is expressed by the satellite as the number of weeks since midnight UTC on January 6, 1980 ("GPS Week") plus the number of seconds into the week. These two values are transmitted as binary integers from the satellites and converted into conventional date (month/day/year) or day of year by the GPS receiver for display to humans. Because the GPS Week number is transmitted as a 10-bit binary integer, it can only count from zero to 1,023. GPS Week 1,023 will end at midnight UTC on August 22, 1999. At that moment, GPS Week number will go to zero and start the count over. Some older GPS receivers may have difficulty displaying the date properly after that, but they should continue to navigate fine.
In testimony before Congress on October 29, 1998, FAA Administrator
Jane Garvey stated that the FAA had completed Y2K-related assessment of all computer
systems and renovation of 99% of all "required" systems. She further stated that
while plans called for complete replacement of the ATC HOST computer systems that run the
ARTCCs by the end of 1999, the agency had completed software renovations of the existing
HOST system in July, 1998, just in case the upgrade to the new system winds up hitting a
snag. She stated that all FAA systems would be completed with end-to-end tests conducted
at the FAA Technical Center in Atlantic City and at the Denver ARTCC, and be fully
certified as Y2K-compliant by the end of June, 1999. Raymond Long, FAA's director of
airway services and its point man for Y2K issues, also says he's quite confident that ATC
will carry on as usual on January 1, 2000.
Most other government agencies appear to be in equally good shape. The Nuclear Regulatory Commission, for example, identified seven mission-critical computer systems with potential Y2K problems. Four have been repaired or replaced already, and the other three are on-schedule to be fixed by March, 1999.
The Pentagon has identified more than 2,500 mission-critical systems. (They take
themselves sooo seriously!) But Deputy Defense Secretary John Hamre has testified that 95%
of them will be fixed by the end of 1998, and that the remaining 5% will be fixed or
replaced in the first half of 1999.
What about Wall Street? Nick Magri, Y2K coordinator for Security
Industries Automation Corporation which oversees technology for the NYSE and ASE, says the
stock exchanges and its member firms will be ready for Y2K by the end of 1998, giving them
all of 1999 to test and retest everything. Bob Lynne of Bank of America, largest bank in
the U.S., says BofA will also have all of its systems Y2K-ready by the end of 1998, and
anticipates no problems, not even recalcitrant ATMs.
There's no question that some Y2K problems will show up after the witching hour on New Years Day of the year 2000, but the vast majority of them will simply be annoying, not crippling. A classic example is your old roll-fed fax machine that doesn't know how to deal with the date rollover properly. The result is that header lines on the faxes it sends in January, 2000, will contain a funny-looking date. The machine might require a chip change or board swap, or you might even want to replace it with a modern plain-paper model. But until you do, you'll still be able to send and receive faxes, so it won't exactly grind your life to a screeching halt.
A lot of Y2K problems will be like that: annoying but not fatal.
What about the often-cited claim that the computers controlling the nation's electric power grid will go nuts on January 1, 2000? Doesn't pass the smell test, says the Y2K guru for Pacific Gas & Electric, one of the largest electric utilities in the country. According to PG&E, any unresolved Y2K problems might affect billing systems, regulatory compliance and maintenance, but no impact is expected on the actual distribution of power. Most power is routed manually, they explain, and automatic controls operate on the basis of load, not dates.
Most Y2K problems can be worked around easily until they're properly fixed. For instance, date fields that accommodate only two-digit years will ultimately have to be expanded to four-digit representation. But in the meantime, a popular quick work-around is simply to establish a "pivot year" to properly calculate the century part of a two-digit year. For example if 40 were used as the pivot year, then a number less than 40 would be interpreted to mean a year in the 2000s, while a number of 40 or greater would be interpreted to mean a year in the 1900s. For the majority of date-sensitive applications in which valid dates can be assumed to fall within some 100-year range, this "hack" works fine until a more elegant solution can be implemented.
Even if some crippling Y2K glitch were to make it through compliance testing somehow, and then suddenly show up on millenium morn, so what? We deal with computer failures all the time. Every critical computer system has backups and fallback procedures in place to ensure that life goes on even if the computer goes down. So long as these failures are isolated exceptions rather than the general rule, they'll be nothing that can't be handled. And if you've read this far and still believe that a massive computer meltdown will occur at the stroke of midnight, then I guess maybe you better pack up your cash, food and ammo and head for the hills.
We in aviation probably have less cause for concern than most industries. First, as I've pointed out, the industry is in darn good shape Y2K-wise. Second, we probably have more backup systems and manual reversion procedures than anybody else. Both pilots and controllers tend to be very current on these procedures -- pilots because they're required to go through frequent recurrent training with emphasis on simulated emergencies, and controllers because they deal with real computer failures so often.
More importantly, lift is what keeps planes aloft, not computers. I suppose one could argue that certain embedded computers (notably FADECs and fly-by-wire control systems) do keep planes up, but those computers could care less about dates, not to mention that they've been stress-tested up the wazoo.
Computers don't keep planes from colliding, either. Pilots do. Just ask any pilot who was flying in Northern California on Wednesday morning, August 9, 1995, when Oakland Center experienced a total blackout that took out all radar and radio communications for 45 minutes. There were no midairs or even NMACs. Nobody freaked out in the cockpit (although I understand some well-chosen words were being uttered on the ground). Center frequencies were magically transformed into CTAFs as pilots started chatting among themselves, trying to figure out what the heck was going on. Flight crews discovered that they could actually fly without clearances, and that airspeed and Bernoulli continued to do their things even without help from the ground. Pilots looked out the windows a bit more intensely than usual, dusted off their NORDO procedures, and occasionally bent some FARs. In the end, everyone got where they were going, no metal was bent, and nobody got violated. Imagine that!
My favorite summary of the Y2K problem was one I saw posted to a newsgroup by Martin Brock:
Y2K won't be a widespread system breakdown. Most systems won't be affected by it at all. Most systems which are affected by it will already have been fixed. Most systems which will not have been fixed will be easily remedied with an upgrade or work-around. A few systems will create isolated havoc. Some bills will be mislabeled, some databases will be corrupted, some servers will go down. But, no planes will crash, no pacemakers will stop ticking, no power grids will shut down, no markets will cease to function. The Earth will turn, and the Sun will rise. We simply haven't turned control of the world over to computers so thoroughly yet. We know them too well.
Despite all this, however, the ultimate Y2K irony is that the doomsayers may wind up having the last laugh after all. If the media continues to pander to public panic, mass psychology alone could lead to an economic catastrophe at the turn of the century. The U.S. stock market is frothy, with individual investors (who tend to be nervous anyway) heavily invested in equities. The sharp correction in the summer of 1998, apparently in reaction to economic problems in Russia whose actual effect on the world economy was barely at the noise level, demonstrates vividly how little loss of confidence it takes for the stock market to crater. Imagine what could happen, then, if a significant percentage of investors actually believe the millenium apocalypse scenario. In the words of noted sci-fi author and futurist Jerry Pournelle:
The situation is serious, but it will not be grave unless we make it so. Widespread sales of stocks, withdrawal of money from savings and the exaggerated hoarding of food, fuel and inventories can transform the Year 2000 bug into a major disaster. ... Franklin Delano Roosevelt once said the only thing we have to fear is fear itself. That is the best mantra for considering the Year 2000 problem.
-- Mike Busch (co-founder and Editor-in-Chief of AVweb)
|
SELECT AND USE OUTDOORS AND SURVIVAL EQUIPMENT, SUPPLIES AND TECHNIQUES AT YOUR OWN RISK. Please review the full WARNING & DISCLAIMER about information on this site. |
Publisher and Editor: Doug Ritter
Email: Doug Ritter
URL:
http://www.equipped.org/y2kbug.htm
Revision: 03 December 14, 1998
Email to: info@pulvertech.com
© 1998 Michael Busch - All rights reserved. Check our Copyright Information page for additional information. |