Personal tools

However, among our own ranks is an ambivalence about the millennium bug, or the year-2000, or Y2K, problem. While one CPSR member stated that Y2K "is absolutely the most important CPSR issue for the coming year," another insisted that Y2K is no different than any other issue of computer risk, and a third worried that CPSR would join the media bandwagon or be seen as one of the doomsday groups.

We may not have to worry on that last score. A recent issue of the New York Times Magazine neatly divided the millennium watchers into categories such as "Christian doomsday," "U.F.O. deliverance," "Y2K chaos," and "avenging planet." The Y2K risk has prompted the formation on one survivalist group in the hills of Arkansas awaiting Judgment Day [1]. We would have to go out on a thin limb indeed to outdo the apocolypters. We do, however, think you will enjoy both our section on Y2K humor and the "The Century Syndrome" from Arthur C. Clarke's 1990 novel The Ghost from the Grand Banks. By email from Sri Lanka, Clarke generously allowed CPSR to publish the book chapter, which envisions financial fallout from millennium computer problems.

Though not extremists, we in CPSR are devoting this newsletter to Y2K because there is no escaping the unique features of this problem: the universal date for concern, the uncertainties, the technological causes. These technological causes prompted the article "A Perspective on Y2K" by Peter Neumann, who won the Norbert Weiner Award in 1997 for his work documenting computer risks. He views Y2K as a serious concern and also as the tip of a much larger iceberg of computer risk.

This global deadline has handed CPSR a gift, a "teachable moment" when the community wants to listen. That's an odd thing to say about the possibility of frustration and hardship, but it's true. People are looking for answers, for reasons. President Clinton mentioned Y2K in his State of the Union messageit is becoming a household word. Y2K provides us with an opportunity to let others know about computer risks and incorrect assumptions, about reliable technology and sound programming practice. As Gary Chapman, former Executive Director of CPSR, writes in his article "Now for Another Daunting Y2K Task: Educating America's Masses," we have work to do.

The Problem

Does "01/01/00" stand for January 1, 1900 or January 1, 2000? That's the simplified translation of the date-sensitive computing glitch. The real explanation is a bit more complicated. The Y2K problem originated with a standard accounting practice used before computers became ubiquitous. That practice was to write the date with two digits, as in '39 or '51 [2]. Early programmers found it natural to continue the abbreviation, because as Don Million wrote, "Back then a 630-megabyte disk drive was about the size of a 30-gallon trash can, and cost as much as a new car" [3]. Wasting two characters every time a date was stored seemed foolish. Also, programming itself was more time-intensive and expensive, and spending hours writing a date routine that would deal with 2000 would have seemed wasteful of scarce resources. Later, when computing became less expensive and less labor-intensive, the year 2000 could be handled more easily. As the millions watching the 1999 Super Bowl learned from Apple Computer's clever HAL commercial, Apple computers have been date-compliant from their beginning.

Yet other producers didn't deal with 2000 properly, and computer chips and startup systems are configured incorrectly to deal with time. Even though memory and storage became cheaper and programming more efficient, date-sensitive errors continued to occur. Today, IBM-compatible personal computers (PCs) have Y2K problems and must be checked for compliance. In fact, PCs using 486 processors or lower can be expected to have century-date problems, and some pentium processors are not year-2000 compatible either, according to the Federal Reserve Board (http://www.bog.frb.fed.us/y2k/pctesting.htm).

We must also remember that the phrase Y2K can refer to any date-related malfunction during 1999, such as 04/07/99, the 99th day of 1999, because the numbers 999 were once used to indicate the termination of a computer program. Some computers could thus terminate when they reach 9999. Another date that some programmers worry about is in the next millenium, 02/29/00, the leap-year day. Many date-associated problems are possible (see the CPSR Y2K Working Group Web pages for more details). In this article and throughout the issue, the term Y2K includes related problems of date sensitivity and date compliance.

We can revise and correct software code for computers, but what will we do about embedded systems? The Institution of Electrical Engineers (IEE) has mounted vast quantities of information at http://www.iee.org.uk/2000risk/. Embedded systems are single- or multi-purpose devices than exist within a larger product, be it a coffee maker, a car, or a missile. Although only a small percentage of these chips will not be date-compliant, we don't know which ones they are. If we do find the chips that will fail, how quickly can we replace them?

Think of the problem this way: a worker may have access to three or four PCs, including laptops and personal assistants, perhaps using Windows 95 or Windows NT. Some of these machines may be old and all have a variety of software added by former users. Perhaps one of these machines is dependent on a network involving the hundreds of computers in a building. When that machine is attached to the Internet, the number of switches and routers and computers that the worker depends upon grows astronomically. A small failure anywhere may have consequences far beyond a single cubicle. Of course, a failure in the computer-dependent power supply will render computers useless anyway.

James Gleick said that "dawn will break on Sunday, January 1, and the Western calendar will turn to the year 2000 C.E., and the sky will not fall" [4]. The severity of the computer problems may be slight, or as Howard Rubin says, at worst Y2K will be the weather equivalent of a sunspot barrage, as if we had natural disasters in scattered locations at the same time. If nothing big happens, our worries could then concern things that we cannot touch or feel, such as slight errors in financial statements.

How about celebrating in Times Square on New Year's Eve, 1999? That would not be my choice, because large population centers could suffer discomfort if traffic lights or utilities were to fail. However, forewarned is forearmed, and if everyone in Times Square watching the crystal ball fall were aware that they might undergo delays caused by malfunctioning of traffic lights, no harm would be done. It's all a matter of education and awareness.

We in CPSR should inform people about what we know and what we don't, and help our country, local government, services, companies, and families adjust to some uncertainty. Wherever we are, we have to help set priorities and avert spreading panic. After Y2K, we have to replace or fix problem technology. To further that end, Norman Kurland and others in the CPSR Y2K Working Group wrote the letter to the New York Times that appears in this issue of the newsletter.

What Do We Know?

My own research into the risks of Y2K problems reveals that not every computer or embedded chip will be Y2K compliant. In fact, that is probably an understatement. Even if every mainframe problem were repaired, many desktops, palmtops, and laptops might have noncompliant applications on them [5].

The complexity of our credit card systems of billing and records are so elaborate that we might shudder at the thought of making everything work together. We now carry several cards with expiration dates of 00 and 01, and that is scant cause for complacency. Should we feel better because of the reassuring posts we receive in our bank statements? Repeatedly, banks assure us that date-sensitivity will not be a problem, and they may be correct, within the realm they can control.

And even if all computers in the United States work perfectly on January 1, 2000, we have real reason to fear failures in other parts of the world in systems that are interconnected with ours and that we depend upon. A noncompliant system can effect a compliant one. When pressed to identify the countries that are not working hard enough to meet the challenge, Ahmad Kamal, Pakistan's Ambassador to the United Nations, said, "I think it would be self-defeating to try to identify the worst parts of the world. Everybody is in the worst part of the world. All of us are responsible" [6].

China is seriously working on Y2K and has given its airline CEOs an ultimatum for fixing the problem: all the heads of the airlines will be in the air on January 1, 2000. Zhao Bo, Y2K head of the Chinese Ministry of Information Industries, said, "We have to make sure there are no problems in aviation" [7]. By the way, a survey of technology executives who were asked, "Would you fly on January 1, 2000?" turned up 63 percent of the respondents saying "no," in comparison to other travelers, 39 percent of whom answered "no" [8].

China has other concerns too. Since the Chinese use pirated softwareindeed, 90 percent of their software is pirated-their technicians cannot consult the manufacturers about how to fix Y2K problems. Accordingly, the Ministry of Information Industries has trained more than 5,000 freelance fixers who will fan out across the country to work on computer systems, and the government has published a list of emergency procedures for computer users [9].

The Russian government has relied more heavily on PCs and midrange computers than larger mainframes, so its repairs of Y2K will be decentralized. Also, many of its PC-based applications are written in nontraditional programming languages, and Russia has been working to convert Russian systems into more universally used computer languages, such as C++ and Java [10].

Here in the United States, industry trainers are preparing people to fix Y2K coding. Their students may have never seen code before, and the trainers have to expand their short courses to introduce the multitude of problems that appear in existing, or legacy, code. Students need to learn such techniques as data expansion, year compression, full date compression, and conversion to binary dates. These trainers are also preparing the people who answer the help desk/technical support calls to cope with increased numbers and kinds of inquiries. Help workers will need expertise in distinguishing between a Y2K problem and a normal one [11]. Hewlett-Packard offers a three-day course on the planning and implementation of Y2K procedures, good for people in the early stages of coping with Y2K. IBM offers a 12-day course on COBOL for new programmers, a "fast track Y2K boot camp." Some programs are being sent to other countries such as India to have the corrections made.

Obviously, if you make changes in an existing program, you need to test it extensively to ensure that it works or that you have not introduced more errors. Y2K thus opens the door to even more problems.

On the other hand, in some instances,Y2K may be a blessing, because old programs filled with patches and quick fixes will be junked, and firms and governments will spend the money necessary to make long overdue replacements.

Should We Run to the Hills?

The short answer is no. The longer answer is that computer professionals can help communities and organizations prepare for possible computer failures. We shouldn't try to do the work already being done by civil defense experts; we can leave that to the people who specialize in handling emergencies. The Red Cross (http://www.redcross.org/Y2K.html) is one such organization helping to assist in Y2K contingency planning. Our role is to help with the things we know about and to take this opportunity to educate people about what computers are, how they are made and programmed, and what the risks are of relying on them so completely. You will notice the word responsibility repeated through this issue. Tony Ralston, professor emeritus of computer science and member of the CPSR advisory board, gives his impressions of the Y2K problem in "Y2K and Social Responsibility." Ralston argues for finding hard facts and verifiable incidents before talking about any problems with time-sensitive programs. He points out the absence of hard data.

We need to anticipate some failures and plan ahead. Actions are simple: back up your files. Keep copies of all your financial statements. Organizations ought to be ready to send out checks by hand. If railroad signals fail, we can keep freight and people moving by using humans to signal trains onward. Airports can slow traffic to a pace that can be dealt with.

Since we deal with weather-caused disasters all the time, we should likewise be able to cope with any stoppages or shortages from computer failure. Perhaps that explains why concerned computer scientists are focusing on nuclear and chemical hazards rather than the everyday problems. We know what to do when a traffic light stops working, but what will happen in Russia if an early-warning missile-detection computer freezes up? Accordingly, in this issue we devote most of our attention to these questions. Lenny Siegel's article "OOPs 2000: The Y2K Bug and the Threat of Catastrophic Chemical Releases," covers one aspect. CPSR has also been in touch with Helen Caldicott (Physicians for Social Responsibility) and Alan Phillips (Physicians for Global Survival, Canada). They've helped us present statements from prominent computer scientists Khursch Ahmed, David Parnas, Barbara Simons, and Terry Winograd on nuclear weapons concerns. The goal is to remove nuclear warheads from missiles, "de-alerting" them, to ensure safety during the coming years. This theme is dealt with in letters from Alan Phillips and Michael Kraig, "Seeking Help on Nuclear Weapons Issues." For further analysis, you can read Michael Kraig's monograph A Bug in the Bomb [12]. Gary Chapman also focuses on weapons in his article "A Moral Project for the 21st Century: Stop Creating Better Weapons."

The Big Picture

Peter Neumann, Tony Ralston, and others warn us that our society is becoming increasingly dependent on systems that have no owner. As CPSR member Ellen Ullman has written in Salon Magazine:

New York Times

No one left who understands. Air-traffic control systems, bookkeeping, drafting, circuit design, spelling, differential equations, assembly lines, ordering systems, network object communications, rocket launchers, atom-bomb silos, electric generators, operating systems, fuel injectors, CAT scans, air conditioners-an exploding list of subjects, objects, and processes rushing into code, which eventually will be left running without anyone left who understands them [13].

CPSR would like to catch public attention now, at this teachable moment, and use the heightened awareness that Y2K gives us to talk about more than date sensitivity. Let's use Y2K to explore computer risks and our relationship to them. With that in mind, welcome to the Y2K newsletter!

References

[1] Heard, Alex and Peter Klebnikov, "Apocalypse Now, No, Really. Now!" New York Times, Dec. 27, 1998, p. 42.

[2] Holmes, Neville Computer, Nov. 1998, 31(11), p. 2.

[3] Million, Don, "1999: A Mystical Year?" Mensa Bulletin, Jan./Feb. No. 423, pp. 26-27.

[4] Hamilton, Scott, "Diary of a Y2K Consultant: Bracing for the Millennium," interview of Howard Rubin, Computer 1999, 32 (1).

[5] Gowan, J. A. , C. Jesse, and R. G. Matthew, "Y2K Compliance and the Distributed Enterprise," Communications of the ACM, Feb. 1999, 42(2), pp. 69-73.

[6] Kirsner, Scott "Millennium Man," CIO Enterprise, 12(7), pp. 54-57.

[7] St. Petersburg Times, January 15, 1999, as reported in Edupage.

[8]Communications of the ACM, 41(11), Nov. 1998, p 10.

[9] Associated Press, January 23, 1999, as reported in Edupage.

[10] TechWeb January, 15, 1999, as reported in Edupage.

[11] Auerbach, Sarah, "Teaching Methods Change as Time Grows Short," Inside Technology Training, Nov. 1998, 2(10) p. 53.