http://www.wfs.org/gouchen.htm Back to the Future: Y2K Struck D.C. in '71 by John E. Gochenouer The Y2K problem has been thoroughly analyzed, discussed, and written about from almost every conceivable angle. Here is a look at what will happen after 01/01/2000, based on my experience -- that Y2K struck Washington, D.C., in 1971. The troubles began when a computer operator responded to a software query by pressing the Return key instead of entering the current date. As a result of this simple action, approximately 25% of the telephone grid in Washington, D.C., was impacted, including many of the government offices in the area popularly known as "Foggy Bottom." An AT&T officially apparently threatened a lawsuit against the offending organization, and it took almost two months for the organization's business to return to normal. This is how it happened, and the lesson is ominous. In the early 1970s, most accounting systems were still manual. Computers cost millions of dollars each and required skilled technicians and programmers to operate them. When I joined the accounting staff at George Washington University Hospital in 1970, automation consisted of electric calculators and posting machines. Within a year, this was to change. In 1970, the hospital began preparations for automating the accounting systems. In a building two blocks from the hospital was a computer that the university was underutilizing. University administrators had agreed to have the third shift, midnight to 8 a.m., available to the hospital. The hospital administration signed a contract with a local software developer for a patient accounts receivable package, signaling a new era for their information processing. This was my first computer, a 1960s vintage design called the IBM 360/30. This multimillion-dollar machine had 64,000 bytes (not megabytes) of memory and removable disk packs that had five 12-inch disks, with a combined storage capacity of seven megabytes (not terabytes, or even gigabytes) of data. The operating system used 12K of memory, which left a 52K partition that was the maximum allowable size for both programs and data stored in memory. Memory was not RAM, but rather tiny magnetic rings that wires passed through and was referred to as core memory. Given these restrictions, it should be easy to understand why programmers in those days tried to preserve every single byte of memory, including the first two digits, "19," of the year. Furthermore, the date routines for one program were used over and over again in other programs written years later. One of the reasons that there was little concern for Y2K was the belief that the programs would not survive. Almost all programs were "custom" written for organizations and the logic was frequently changed and replaced. Even in the 1980s, computer instructors were telling students that the average life-span of a program was five years. What wasn't being said was that "average" wasn't the important statistic. What was important was the life-span of the date routines in critical applications. The answer wasn't five years, it was decades; and the proof of that is awaiting us at the turn of the century. Such was the computer environment in 1970, when the hospital decided to automate the accounting system. As the young and eager supervisor of patient accounts, I played a key role in converting the manual system over to the new computerized billing system. Everything had to be retyped on punch card machines. Even though the computer allowed the use of tape input, we had to use punch card machines because there was no budget for the more expensive tape entry systems. This was all off-line work. The computer was far too primitive to allow for any on-line work and could only "talk" to its tape drive, card reader, and operator console, which was a big noisy electronic typewriter. After a couple of months of around-the-clock work, the system was ready for testing. As simple as an accounting package might seem today, it wasn't so simple in 1971. There were numerous bugs in the COBOL programs and JCL operating system commands that delayed the implementation date and caused considerable anxiety for the managers and administrators who participated in the decision to automate. But now the problems were fixed, the testing finally demonstrated that the software package was viable, and the information we entered about the patient accounts was reasonably accurate. It was time to throw the switch. Looking back, this seemed like such a crucial moment, but we didn't see it at the time. The participants had tested everything and it worked; we were na�ve enough to think nothing could go wrong. So, having done his work, the hospital accounting manager went on vacation, leaving his trusted 22-year-old supervisor (me) in charge of the first month's billing cycle. The billing was done using continuous forms paper stock called Data Mailers. They were presealed envelopes with carbon paper coatings on the inside so that the billing information could be printed by using an impact printer without an ink ribbon. The non-inked hammers would hit the outside of the envelope, press down on the carbon backing, and create the characters on the blank interior paper of the sealed envelope. The result was that the bills could not be checked unless the envelopes were "popped" open, which would ruin them and result in a manual invoice having to be typed up. For that reason, the information being printed on the invoices could not be seen by the computer operator and there was not much motivation to check them for accuracy since it required so much rework. Neither the software contractor, nor my manager, left any instructions on how to check the bills for accuracy. Around midnight the printing began. Then the Data Mailers were stripped of their spindle feeds, separated on the perforations, and stacked in cardboard boxes for shipment to the post office. Being curious as much as concerned, I went to the computer room near the end of production and randomly took out four of the invoices. When I popped them open and slid out the bill, I found all four of them had a threatening notice printed under the amount owed. The notice stated that the bills were more than 120 days overdue and were going to be turned over to a lawyer for collection. It did not seem possible that all four bills were delinquent since our collection record was not that bad. What occurred to me was that we had put some incorrect data in the file. When I showed the invoices to the computer operator, he agreed that we probably had made a mistake entering some account information so I returned to the Patient Accounts Office to research the problem further. First, I went to the file cabinet, pulled out the original billing information, and found all four to be bills for current medical work. Then I went to the computer printouts and found all four had been entered correctly, which amazed me. How could this possibly have happened? It couldn't have been the programs -- they were thoroughly tested -- and now I knew it wasn't the data either. I made the decision to have the boxes of Data Mailers put in my office until I could get some answers. I couldn't discuss this with my boss because he was out of the country -- in Acapulco, if my memory serves me -- and when I called the software developers they said not to worry about it and mail the bills. Instead, I kept the bills in my office for four or five days while I tried to track down my manager. When I finally reached him on the telephone, he was horrified and angry that the billings had not been mailed. [NOTE: This was another great learning experience for me. It was called Cash Flow and I had single-handedly halted it at a major metropolitan hospital.] I was told to immediately and personally carry the mailers to the post office, which I did. Thus, both the software company and the accounting manager thought I had uncovered some meaningless aberration, inconsequential compared to the loss of cash flow to the hospital. No one knew that an inadequately trained computer operator had received a printed message on his console requesting the current date and that his response had been to press the Return key. When he did that, the date for calculating invoice age became 00/00/1900 and every debt was found to be over 70 years overdue, ready to be turned over to a lawyer. I dropped off the 10,000 mailers at the post office -- 10,000 threats of legal action against people who had recently suffered from a major illness or had suffered a tragic loss. Their mail would soon add to their suffering. In addition to the inhumanity that this mail was about to create was the importance of the geographic location of the hospital. Since it was only about five blocks from the White House and on the boundary of a heavily diplomatic Foggy Bottom neighborhood, a good portion of the patients were political figures or diplomats. We had sent letters threatening legal action to two sitting Supreme Court judges, a retired Supreme Court judge, the attorney general, the daughter of a famous senator, and various ambassadors and cabinet members. The accounting manager had not yet returned from his vacation when the Y2K explosion hit. Within 24 hours of the mailing, the phone system of the hospital and surrounding areas had locked up. My staff was being traumatized by outraged patients who had lost a lung, or had heart surgery, or had lost a loved one. The phones never stopped ringing. The department had five shared lines on a rotary dial. After listening to an unstoppable parade of angry ex-patients, we began leaving the phones off the hook because as soon as they were put back in their cradles they would be ringing. After two days of this siege, the hospital controller came over to our office to find out what had happened and ordered us to put the phones back on the hook since AT&T had paid him a rather stern visit. Their operators were swamped with complaints that no calls could get into an entire quadrant of the Washington, D.C., grid; and upon hearing the reason, AT&T had apparently threatened the controller with legal action. The controller ordered us to take as many calls as possible and as quickly as possible to clear up the trunk lines. Thus, the consequences of one program miscalculating the date were amazingly disruptive to peoples' lives, causing the following major problems: * Excessive phone calls, tying up the trunk lines in a major sector of the nation's capital. * Phones ringing all night and day, disturbing tenants living above the receivables office. * Current hospital patients could not be reached over the phone by worried family members. * Psychological pain and suffering for people already suffering health-related problems. * Crushing work load and poor morale for the receivables staff. * Threatening letters received from the attorney general and others. * Serious damage to the reputation of the hospital. * Accounting manager left the hospital. When he returned from vacation, the manager was apparently asked to resign, which he did. I survived the mess but wound up working a double shift for almost two months. When the bills were run in the next monthly cycle, they had a cover sheet that made it easy to check for accuracy before they were mailed. After these bills were sent, the phone lines started returning to normal, at first only in the early morning and late afternoon and then gradually throughout the whole day. Ironically, the hospital controller was sent a commendation letter from the university vice president of finance, thanking him for an extraordinarily good month that had increased cash flow by $400,000. It seems that most people paid their bills quickly since they only received busy signals when they tried to call the patient accounts office and they didn't want to face the possibility of dealing with a collections lawyer; this resulted in a windfall for the university. Now, back to the future. It is 1999 and thousands of programs around the world are not prepared for the Millennium. The lesson the above story tells us is that only a few errors will bring major disruptions, however brief, to society. Assume for a moment that the above minor error had occurred in only six of the thousands of businesses in Washington, D.C., that are as big or bigger than George Washington University Hospital. The phone system would have shut down in the capital of the world's most powerful country. If that seems ominous, consider the cascading effect that minor errors have had in both natural and artificial networks; computers don't stand alone like they used to in 1971. A problem that may appear to involve only a small local bank in Calcutta may cast ripples of unimagined intensity throughout the who banking system. The same scenario applies to other industries. There is no need for me to document all the systems and networks that are vulnerable. Other authors have carefully completed that task. However, even if the Y2K problem is reasonably mild, there is also the possibility of a dangerous virus striking at that time. Virus writers seem fascinated with time. Viruses have been specifically written to strike on holidays, birthdays, and other dramatic or romantic occasions. The Millennium seems to be too juicy of a target to resist. It's also too juicy for the legal profession to pass up, with rumors that major law firms have already written stock legal briefs in anticipation of a flurry of disruptive, but profitable, civil suits. Therefore, I am firmly in the camp of the pessimists who believe society will suffer a major setback. On the other hand, my D.C. story may indicate that the Millennium presents an excellent opportunity for the stock players. The full impact of the rollover will be felt by mid-February 2000. By then most persons and businesses will have received their screwed up reports, invoices, purchase orders, etc. Since many people will also be feeling an emotional letdown from excessive holiday merriment, the stock market should be at a low level -- a good time to buy technology stocks. Businesses around the world will soon be frantically updating hardware and software to Y2K-compliant levels and this pipeline of orders should begin lifting the stocks of computer firms faster than the other industries. Predicting the future is not easy. Many academicians of the 1950s were so in awe of computers that they were predicting that by 2000, computers would be making all major decisions in the economies of the world and that their level of artificial intelligence would exceed the greatest human minds. But artificial intelligence at that level lies beyond the foreseeable future. The opposite phenomenon will occur, with unsophisticated computers failing to understand the simplest explanation for the double zero in the year. It happened in 1971 and it will happen again in 2000. About the Author: John E. Gochenouer is an associate professor of management and MIS at Barry University, Andreas School of Business, 11300 N.E. Second Avenue, Miami Shores, Florida 33161. Telephone 1-305-899-3516 E-mail <[EMAIL PROTECTED]>. An edited version of this article is scheduled to appear in the August-September, 1999 issue of THE FUTURIST.
