- Shopping Bag ( 0 items )
Ships from: Chatham, NJ
Usually ships in 1-2 business days
Behind Every Great Machine.
The Monster in the Closet.
Avoiding Future Shock.
Ready to Run.
Managing the Fix.
Power to the People.
A Date with Destiny.
Taking a Tool Inventory.
2000: A Tool Odyssey.
When in Doubt, Outsource.
The Price of Failure.
Peter de Jager and Richard Bergeon ISBN 0-471-17937-X
Houston, We Have a Problem
It's New Year's Day 2000 and you're headed to your best friend's house to watch football. You're in a hurry because you don't want to miss kickoff, and you have to stop at the nearest cash machine first, because you promised to bring the beer. But instead of cash, the ATM commandeers your card, rudely informing you that it has expired. Furious, but knowing you won't get much help on a holiday, you head to the nearest 7-11 intending to pay for your refreshments with a credit card. Pulling up to the store, you think a lot of people have the same idea, because there's a long line at the checkout counter. But the problem is not a run on beer; instead, you find out, the cash register is not working. The word, as it reaches you at the end of the line, is that the cash register is computer-based and requires a valid date to start up. And for some reason, it won't. "Some reason" is the Year 2000 problem, Y2K for short.
The preceding hypothetical-but probable-scenario is just the tip of the ice-berg, and if collective public denial continues, it is an iceberg that will sink titanic computer systems worldwide. Like the unheeded warnings of disaster on the oceanliner Titanic, the alert to the Year 2000 problem has been sounded-on television, in newspapers, magazines, and newsletters, and via the Internet. Often, however, it has been defined simply as the inability of computers to calculate properly with 00-two zeros-signifying the new century. Further, media coverage frequently couches the issue in computer jargon, making it seem irrelevant to anyone other than programmers and information systems managers. The truth is, the Year 2000 problem will affect each of us, personally and professionally.
What is the Year 2000 problem? It is not one, but a series of problems, some involving computer software, some involving computer hardware, some involving data, and all involving large amounts of money to fix. The nature of these problems is easily explained. Until 1989, all the standards followed to create computer programs stated that only two digits-the last two-would be used to identify the year, and, to date, this has been an efficient abbreviation. But at the dawn of the millennium-when the year 2000 will be recorded as 00-most computers will regard 2000 as 1900. Thus, computers will treat a driver's license, credit card, passport, or drug prescription that is due to expire in the year 2000 as already having done so.
To understand the disruptions this will cause, it is essential to remember that computers were not designed to do arithmetic but to perform operations involving logic. For example, to determine that a person born in 1945 is older than a person born in 1955, a computer calculates ages and then compares them. In 1995, the calculations were simple: 95 -45 = 50, 95 -55 = 40; 50 compared to 40 is greater. But in the year 2000, these calculations stop working correctly: 00 - 45 = 45, 00 -55 = 55; the computer identifies the older person as being younger. But keep in mind that the last equation should include minus signs, thus: 00 - 45 = -45, and 00 -55 = -55. The calculations should still work. And that would be true if all those early programs had been designed to maintain plus and minus signs when doing calculations on dates. But they weren't. Why not? Simply put, these programs weren't intended to run beyond the twentieth century.
Let's take a look at a couple of birthday surprises already caused by the upcoming new year. Brian Hayes, in his article "Waiting for 01-01-00" in Amer-ican Scientist (January/ February 1995), gives these two examples of potentially typical, albeit humorous, repercussions of the Year 2000 problem.
In 1992, Mary Bandar of Winona, Minnesota, was invited to join kindergarten classes when her name turned up among others identified in a database search for people born in '88; at the time, Bandar was 104 years old.
C. G. Blodgett's auto insurance premium tripled when he was reclassified after his 101st birthday as a high-risk youthful driver.
Don't, however, be lulled into thinking that these anecdotes are interesting only as sound bites during the feel-good portion of a nightly newscast. They are symptomatic of potential worldwide disruptions in business, transportation, finance, and much more. Let's get a little more serious.
Say you make a deposit to your personal or business bank account at the end of 1999, then write a check or make a transfer in 2000. If the bank's computer regards 00 in the date field as 1900 (as most do), it will treat the withdrawal as if it were made before the deposit, and your personal and/ or business accounts will be overdrawn. Now are you beginning to see the problem?
Another dilemma is that back in the good ole days, when people thought 2000 was a long time away, programmers felt safe using the digit pairs 00 and 99 to indicate either keep forever or delete now. Thus, 99 is commonly used to terminate processing. One organization realized nearly six months into 1994 that its computer was discarding files that were supposed to be stored for the next five years because it was programmed to purge data with 99 in the year field.
Storage space intended for dates has long been used and abused. One retailer, while investigating the possibility of a computer crime, discovered that the year values 94, 95, 96, and 97 were being used to indicate that discounts of various amounts were to be applied. And although some foresighted companies had specified that date fields were to include space for the century, programmers had done nothing to verify that it was done. Worse, in some instances they found that the space had been used to store other data.
Leap of Math
Now consider the following: Shortly after February 29, 1988, a supermarket was fined $1,000 for having meat around one day too long. The problem was traced to a computer that didn't adjust for the leap year. What does this have to do with the year 2000? Read on.
To determine what to do, computer programs refer to internal calendars, most of which were designed to run only through the twentieth century. And while 1900 was not a leap year, 2000 is. If you're as confused as most programmers about how to determine this, here are the three rules for determining a leap year: Rule 1 says that if the year is evenly divisible by 4, it is a leap year. Since 2000 is divisible evenly by 4, it must be a leap year. Not so fast. Rule 2 says it isn't a leap year if the year is also divisible by 100. And 2000 is divisible by 100 as well as 4. So it isn't a leap year, right? Wrong again. There's rule 3: When the year is also divisible by 400, it is a leap year and does have a February 29, which includes 2000 (technically, it's a leap-century day). When 2000 arrives, if your computer treats it as 1900, it won't account for February 29, because there wasn't one that year. Needless to say, there are many computer calendars out there in which every month will be off one day following New Year's 2000. Consider the implications of that on computers that are dependent on date data to manipulate security systems, traffic signals, train and airplane arrival and departure information, and surgery schedules at hospitals.
Up from Denial
Make no mistake about it, the Year 2000 problem is starting to generate considerable attention. Nevertheless, Ed Yourdon, editor of Application Development Strategies and a widely renowned information systems specialist, conducted an informal survey that convinced him that this attention has not translated into appropriate levels of concern. His impressions were supported in a May 23, 1996, article in Washington Technology, which indicated that two-thirds of the "infotech" executives surveyed believed the Year 2000 problem was not a high priority, three-fourths of program officials believed it wasn't a high priority, and one-half of information technology executives planned to wait until 1998 to take action. Finally, a survey in the February 1996 issue of Information Week indicated that 50 percent of the U. S. data-processing organizations will not have their software converted by December 31, 1999.
And of those corporations that are actively engaged in solving this problem, most are not speaking out about their efforts. Neil Cooper, a stock analyst with Cruttenden Roth, who is working on the Year 2000 problem, offered the following reasons for this conspiracy of silence:
Fortunately, not all organizations are waiting for the ball to drop in Times Square to tackle this issue. A number of companies have completed the initial project-estimating phase, although few have embarked on the fixing stage. Many are still suffering from what car buyers refer to as "sticker shock." Others are trying to determine which computer applications must be saved, which will cost less to replace than fix, and which can be fixed as they break down. Still other companies are so dependent upon computer hardware and software purchased from other companies that they must wait until the vendors address their own internally developed programs.
At Massachusetts Mutual Life Insurance Company, Ron Cote, a Year 2000 project leader, calls his effort a "survival project." "If we don't do this," he says, "it's shut the lights off and go home." So far, the workarounds developed by this organization's information systems people have proved unsatisfactory, and they have 45 million lines of code to change and then to test. Mass Mutual wants to complete its project by the end of 1998, which will provide a one-year cushion. The company has been aware of this problem for more than 10 years.
It is important to realize that many industries have become totally dependent on computers to function. Insurance companies, banks, securities brokers, and many more have become data-processing firms. They get data, send data, and use data to function. Without their computers, they simply would not be able to conduct business. And computers that are not programmed to accept values of 00 in the year field will not run. Don't forget, computer applications are highly integrated. Data from one application often is required for the next to run successfully. If the first one doesn't run because it confronts a value containing 99 or 00, any program dependent on it won't run, either; call it the domino effect.
Complicating the situation is that many programs run in strings, making it difficult to determine which program failed. Finding the problem in the first might only get you to the next in the string, which might subsequently fail. And each failure may take hours to correct. The system failures ultimately overwhelm the people who can correct them. If these problems occur in systems taking orders, paying claims, or issuing paychecks, the companies dependent on them will quickly lose credibility and will be in violation of regulations.
Consider the city of Phoenix, which found out about the Year 2000 problem the hard way. On January 2, 1995, a simple application that calculated five-year payments crashed. When the program tried to subtract 95 from 00, it couldn't handle it. Jack Thomas, the city's information systems deputy director, considers the crash a blessing in disguise, for if the application hadn't failed, the city could have begun calculating inaccurate payment schedules with potentially disastrous results.
An analysis by Viasoft, a tools contractor that began tackling the problem in Phoenix in 1994, found that more than 90 percent of the city's programs use date routines that cause problems. He estimated it would cost that municipality $63 million to fix its Year 2000 problem throughout 14 major applications that support several major city departments.
Financial services companies that know they will be impacted by the Year 2000 problem include Abbey National, Lloyd's of London, Barclays, and NatWest- and that's just in Great Britain. This, naturally, comes at the same time that work must progress for conversion to a single European currency unit-ECU. Other countries in the community, of course, will be facing the same dilemma.
Other institutions and companies that have invested in fixing their Year 2000 problems include many banks: BankBoston, Canadian Imperial Bank of Commerce, Fleet Bank, Nations Bank, and Sun Bank among them. Manufacturers such as Philip Morris, Shell Services, and Texaco (to name just a few) are also engaged in correcting the problem. Some firms, such as Kaiser Permanente and Union Pacific (both of which have participated in important conferences and roundtables on the Year 2000 problem in order to share what they have learned), have already begun, or are close to completing, conversion of their computers to cope with the Year 2000 problem.
In 1991, the northern California division of Kaiser Permanente started setting up a team of about 20 outside contractors and 10 internal staff to begin working through its computer applications. The team expanded date fields to allow for century values, then added the century values to all the current data; it also backtracked into historical data to add the century values. It removed all queries to the hardware manufacturer's date routines and installed its own. Finally, it created a standard set of date-processing routines and replaced all others with them.
In 1995, Union Pacific hired a consulting firm to assess the approximate cost of fixing its computer systems to handle the new century. In 1996, it commenced its project. In some cases, the update team expanded the date fields to support century values and changed the data. In others, it inserted logical date interpretation processes so as not to change the data.
BankBoston set up a special staff to perform date-field expansions. The application support teams send programs to the staff, who expand the fields and replace date routines with standard routines. Any logical processes that must be changed are identified; the altered programs are returned, along with pro-grams to handle data changes, to the application support teams who must change the programs to fix the logic problems and test them.
As always, when someone loses, someone wins. It is easy to imagine that some firms are already building war chests, to acquire companies that fail to survive the countdown to double zero. In fact, more than one company insider has indicated that it is a strategy under discussion. Some companies are already benefiting from their lead in fixing the problem. Kaiser Permanente won a corporate contract for group health coverage when its nearest competitor confessed that it was doing nothing to prepare for the year 2000.
Are you starting to wonder how you and your company or organization will be affected? So far, there are no silver bullet solutions to the Year 2000 problem, although certainly many hope for such an easy way out, exemplified in this statement in the August 3, 1996, issue of The Economist: "This is doubtless a technical feat that Microsoft or some other firm will shortly master." Microsoft was having enough trouble dealing with the most recent fallback to daylight savings. As reported in PC Week on November 4, 1996, in Spencer Katt's "Rumor Central," at 2: 00 A. M. on the morning of daylight savings' Sunday, those who turned their computer clocks back (as prompted on-screen) discovered that one hour later, it was 1: 00 A. M. again. Fortunately, few people were up working at that hour. The point is, it would be foolhardy to wait for anyone to deliver a quick fix to the Year 2000 problem.
But it can be solved-today. Like a genetic disorder, the solution lies in finding each mistake in the code-in this case, program code-and fixing it. The bad news is the code is often difficult to find and thus to correct. The good news is enterprises that are well into the millennium update are already reaping significant benefits. Some have won new contracts simply because they can demonstrate preparations are in process. In some situations, budgets that have been restricted over the last few years are being relaxed, allowing organizations to upgrade systems software and hardware. Fixing the Year 2000 problem will enable growth of new functions and potentially decrease support costs.
Our goal in this book is twofold: (1) to convince you that a problem does exist that will affect you and your business, and (2) to give you the insight into how to start doing something about it. Chapter 1: Ground Double-Zero
S o much anthropomorphic terminology has found its way into the computer technology lexicon that we forget computers are machines: They can't really "think" or "see," and they don't really "know" anything. When we see the date 01/ 01/ 00, we know it refers to January 1, 2000; when the computer "sees" 01/ 01/ 00, it "knows" it is January 1, 1900; or it might "know" to delete the information accompanying the double-zero number string. The looming dawn of the millennium is going to require that we stop trusting our computer systems to know anything other than what we have programmed them to know. It is time to take responsibility for not being farsighted enough to plan for their future use beyond the year 1999.
Programming began on punch cards known as Hollerith cards, named for the man who invented them in the late 1800s in order to get the U. S. Census done on time. Each Hollerith card had only 80 columns, and all information for each record had to fit into those 80 columns. How could early programmers have guessed that one of the shortcuts they developed to accommodate that 80- column restriction would one day result in a data nightmare? To save space for more important information, early on, the year designation was reduced to two digits. The assumption-then rightfully-was that everyone knew the century prefix was 19.
Over the last 50 years, we have gone through countless upgrades of computer technology. At some point, you or your enterprise wanted or needed some feature that required a new computer. The decision was made, the budget was secured, and you bought the new model. The old one was sent to some computer equivalent of an elephant burial ground. You remember what came next: conversion, the process during which you tried to get old programs to run on new equipment. Code was written on the fly, often without documentation, to keep the system up and running.
Through all these years and all these conversions and upgrades, we have been stuffing an ever increasing amount of data into computers. We have tons of it stored on disks and tapes, in huge vaults, and in closets and caves. We also have duplicate data, because most key files are duplicated daily. There are even copies of copies. And for the most part, we have stored this data in large files in date sequence according to when it was collected. Many of the structural programs-the ones that handle physical resources such as tape and disk management, scheduling, and communications-can't manage a four-digit year at all. Business applications depend on these structural systems. If they can't figure out how old you are, how long an invoice has gone unpaid, which transaction should be processed first, or how much interest they owe, the companies that depend on them are in big trouble.
Out of the Closet
These closets full of old data complicate the challenge of making the programs and computers in daily use Year 2000- compliant. Few companies have maintained conscientious code documentation; fewer still can boast that the programmer who wrote it is still on staff. Without documentation, without the programmer( s), the solution is easy to describe, but mind-boggling to implement: Examine and correct each and every line of code and then fix the digit-deficient data residing in all data files, or write new systems able to handle the problem. A single program could have from 10 (a 4GL program) to 100,000 lines of code, and 1 in 20 lines of code have something to do with defining or processing date data. In terms of functions performed, this means that nearly 5 percent of all data-processing operations are impacted by dates. If you look at a medium-size organization with 4 million lines of code, it will have to visually scan, one by one, every line to find 200,000 instances of date usage. It will then have to make approximately 20,000 changes, requiring not less than 13 hours (based on the authors' prior experience in making a similar enterprisewide update) to design test data, create a program to build the test data, and run the tests for each group of about 10 changes. This means that it will require, without some form of automated assistance, 26,000 hours (roughly 13 person-years of uninterrupted attention-no coffee breaks, training time, waiting for equipment, or downtime) to make and test all changes. Then you have to factor in the misses: Every time a change is missed, it will take four to six hours to find and patch the code. And don't forget, the changes must be scheduled in the proper sequence. At any one point in time, it may be necessary to have 60 people making changes so that all interrelated programs are altered simultaneously. Conversely, at another time, only one person may be able to make a change so that 60 others can start working together.
The cost of accommodating all that old data is staggering. Worldwide, the estimate commonly used is $600 billion with up to $300 billion borne by the United States. While U. S. government estimates currently amount to only $50 billion for business and $50 billion for the federal government, there is extreme skepticism on the part of reviewers. Reports of expenses have been highly diluted by failures to account for work not directly associated with program repairs. The major banks each are dedicating hundreds of programming personnel to convert all existing and developing systems to accept the change from 1999 to 2000. All that old data either must be changed or someone must go into every program and put in some code that essentially says, "If the year is greater than 49, pretend that there is a 19 in front of it, otherwise pretend there is a 20 in front of it." Easier said than done. Some dates are not so easy to expand, which brings us to the issue of embedded dates and date stamping. Whatever the actual cost, this we can be sure of, the problem must be fixed. Cost is not the issue; time is now the only important factor.
Getting Embed with Dates
Embedded systems are everywhere. Computers with wide ranges of capabilities have been installed into more and more of the equipment used daily. Alot of people are wearing fancy watches that do all kinds of nifty things with calendars; some of those will stop working when the date rolls over on December 31, 1999. Those in your VCR may cause minimal problems, as there's nothing to record between midnight and 8 A. M. on January 1 anyway. If you plan to set your recorder to record a game, though, you should check it to see if it works (assuming you know how to program your VCR in the first place).
Embedded business systems control lights, elevators, security systems, time clocks, and heating and cooling systems. They are in the scales in receiving, in conveyors on the shop floor, and in emissions-monitoring and waste-removal systems. They control cutters, molders, and pressers. They turn lights on and off in your parking garages and lots. They are in the monitoring equipment in hospital operating rooms. In short, embedded systems control the conditions in which you work; sometimes they even determine whether you work. The problem with embedded systems is that they run in the background, and currently most are running in obsolete equipment. This means that you can rarely just reprogram them; you have to replace processors, circuit boards, and sometimes the whole unit-major expenses, needless to say. Banks, for example, have been finding that not only do some of their ATMs have to be replaced, but also the kiosks in which they are mounted, because the new units are smaller than the older, bulkier ones.
Embedded systems are one problem; embedded dates are another. An embedded date is one that is used as a component of a longer character string to uniquely identify a particular item or event. Embedded dates are commonly found in invoice numbers, such as 94090013, where 9409 is the year and month of issue. They also appear as parts of policy numbers, license numbers, merchandise sales tags, storage bin tags, transaction numbers, and date stamps.
These dates are built into the data that you retain and use daily. The worst of these appear in the key fields you use to determine where and in what order you store data. Others appear in date stamps you use to track data and processing actions. Embedded dates typically appear in four formats: Table not included in web version of Chapter 1 When dates appear at the beginning or end of the field, they are often used for intelligence-to provide the observer with status information. When a field contains an embedded date, the following questions must be answered:
Is it used to determine item aging or age?
Is it used to sort the item into sequence?
Is there a calculation being made?
Dates appearing at the beginning of the identifier create another difficulty. Some application software automatically suppresses leading zeros in numeric fields, causing miscalculations because 00 may be treated as null data and thus be rejected or result in a miscalculation or zero-divide errors.
For example, one apparel retailer that uses dates as a prefix to its stock item numbers spent several millions of dollars on encoding and scanning equipment that could read the garment number. But because the scanners had a limitation on the length of the scan, the date field could not be lengthened; the other characters and digits were equally significant and could not be dropped or truncated. So, if the century field could not be added, all this retailer's inventory dated 99 or earlier could not be tracked correctly, meaning they wouldn't be aged for distribution, disposition, or markdown. Unsurprisingly, this retailer prefers to remain nameless.
Another example was reported in The New York Post on July 4, 1998. A large retailer was surprised when its computerized inventory management and pricing system put entire shipments of new inventory on the shelf at huge discounts. The problem was traced to the program that discounts items if they are not sold in 21 months. But because 21 months from now falls in the year 2000, the system became confused and, assuming these products had been sitting around since 1900, slashed their prices.
Date stamping is another intelligent use of embedded dates in records. Date stamps are automatically placed on the record by the system for such things as transaction tracing and backup recovery. However, date stamps often create problems as the formats change; for example, old data is not recognized by the new recovery routines. If changes are not made, the transactions or records may be processed out of sequence. The results could be as described by Brian Hayes in American Scientist (January/ February 1995):
At the local dairy, the oldest milk on hand is supposed to be shipped first, but in the early weeks of the new millennium milk from year 00 is given precedence. Indeed, any milk remaining from December 1999 will not be scheduled for shipment until the end of 2099. Meanwhile, at the bakery across town a computer calculates the bread dated 01-01-00 must be a century old, and sends it to the landfill. The next example actually happened. A British retail food chain was found dumping loads of cans of tomatoes due to be sold by '05 because the automated system designated them to be expired.
Extend these examples to blood donations, medicine prescriptions, and medical records and you have genuine disasters in the making once 00 makes its way into the data stream.
Certainly code can be fixed for applications created in standard languages, which are well understood by a sizable number of programmers. However, when some unique language such as JOVIAL or APL is involved, costs increase dramatically because of competition for rare resources (those who know the language). Which brings us to one of the key issues in the Year 2000 problem.
No Comprendo COBOL
By some estimates, the number of computer languages in use totals more than 300, including various coding dialects. A few major languages, such as COBOL, BASIC, FORTRAN, and C, probably account for 80 percent of the pro-grams running today, but each has several dialects and versions. Fortunately, most of these are relatively easy to understand, and if a programmer knows one dialect, he or she can learn the others.
Other languages, however, are more obscure, either because so few programmers ever learned the language, or the language enabled the programmer to write in a way that kept the code inaccessible and thereby tamperproof. Thus, in one such program you might see the letter A used to signify a storage location for a person's name and B used to identify date of birth. In the next pro-gram, you might find the same letters used to identify totally different things. (One programmer actually bragged that his efficiency was due to the reduction in keystrokes it required for him to write programs. Imagine a system in which the programmer keeps the whole system's data mapping in his head.)
Other update complications are based on original attempts to save space, while still others relate to the attempt to reduce the costs of data storage and communications. Compression of numeric data and zero suppression on computer terminals are examples. It is hard to imagine that not long ago, less than 15 years, a 2400 bits per second transmission speed was a performance target in data communications. The cost of memory was so high that 32MB of memory (that of a typical PC today) cost about $256 million.
A few attempts to save costs have resulted in imaginative data-storage strategies. People have confronted situations where the dates look encrypted: A year may be assigned the value of A, the next year B, and so on. These date formats are referred to as interpreted. The format of the field may appear as YDDD, where Y has an alphanumeric, or even symbolic, value. In other formats of YMDD, both year and month appear with values of 0 to 9 or A through Z. This is, by some measures, very efficient. The single digit gives the system a date range of up to 36 years. Surely every program should have been replaced by then?
Where different versions of the same language exist, the issue is one of effort. Old versions of compilers are not maintained. For example, IBM mainframe COBOL has been changed only in the two most recent releases to accommodate century information. This means that all older releases are not able to read the new dates using the IBM-supplied routines. Upgrading those older releases means that the companies have to go through many thousands of additional hours of work (which is why they weren't changed in the first place). IBM is not alone in requiring licensees of language compilers and assemblers to upgrade to the latest version. Hewlett-Packard, Unisys, Digital Equipment, Oracle, and others have all released upgrades of languages containing date-related changes to allow programmers to handle the Year 2000 problem. Then there's the problem of language obsolescence. Many languages are literally dead. They continue to work, but nobody knows how to change them-and even if you could find someone to change them, there may be no compiler or interpreter still available to turn them into functional code that the computer can understand. Example: IBM created a product called ADF in Europe in the early 1980s. Several million lines of code were written in the language. In 1989, IBM abandoned ADF. Consequently, Big Blue won't (can't) fix it to handle four-digit year designations, and running the programs requires having an active interpreter on the computer at the same time. The interpreter doesn't handle century dates. What does a company still using ADF do? Its choices: Completely rewrite the code (assuming someone knows what it does); figure a way to fool the interpreter and insert that logic everywhere it is required (assuming you can find enough programmers and train them); find a way to convert the code to COBOL (one does exist, supposedly) and then convert it (assuming you can afford the time to find the vendor, learn how to use the tool, convert the programs, and make the changes before the system collapses).
There are approximately 200 other obsolete and/ or unsupported languages. The list includes older and widely used versions of COBOL, RPG, Natural, and FORTRAN. Many organizations are facing stiff requirements in updating programs in languages such as RAMIS, Easytrieve, Lisp, Prologue, and so forth where there are few people with the language skills available. Such languages as APL, Dibol, Metacobol, and Total were widely used and some pro-grams are still being run in these languages.
Counting the Costs
Computers have worked astoundingly well in the past. They will do so again in the future. But between now and then users will all be in for a wild, rocky, and expensive ride.
It may seem inconceivable that a couple of zeros in a date could multiply so dramatically into some very large repair bills, but that is what will happen as you prepare to fix the Year 2000 problem. To ease you into this awareness, consider controllable costs, which fall into two subcategories: (1) internally developed computer systems and (2) business practices and operations. Application Software
Most large organizations have a large number of internally developed pro-grams. John Pasqua, AT& T's Year 2000 head, in public testimony indicated AT& T has over 3,000 applications and will spend $500 million by December 1998. Midsized firms are more reliant on commercial systems, depending on packaged hardware and software for processing or subcontracting their data processing. The latter are expected to incur heavy costs associated with updates to new versions of software or replacement of systems. It is the very large companies that will experience most of the code-fix problems.
In addition, with old programs, the large firms have the challenge of locating the source code. And assuming the source code can be found, there is the problem of verifying it is the same version of the programs that is currently running on the computer. Many of the large firms and agencies could be forced to re-create programs whose functions are no longer understood by anyone in their organizations.
In many cases, no one in any given organization knows where all the programs are located. Many organizations report finding applications two years after the original inventory was taken. The U. S. Social Security Administration announced that it had overlooked nearly 30 million lines of code when it set its programs three years earlier. It is not unusual for programmers' original code to be stored in public and private libraries or in archive files that are not even on the computer. Programmers actually keep tapes in their desk drawers. With programs now being created by accountants, engineers, scientists, and general managers, it can take years to discover programs that are in daily use. Thus, it is also not unusual for even a well-organized programming department to require three months or longer to find the code it owns. If and when it does find it, often it is not sure what it is that's been found.
You will learn, if you don't already know it, that the program versions running on your computer are not always the same ones that match the code you found. It is not unusual for companies to lose source code of programs that have not been changed for a long time. Up to 40 percent of a company's port-folio is not touched for five years or more, and many programmers lose track of code that is often obscurely named and not well managed. Consequently, you will have to hire or delegate someone (perhaps several people) to find these missing program versions and match up the running programs with the programmer-created code. To a noncomputer person, all this talk of code, source, and compilers may be confusing, so please allow a minor digression.
Programs are written in a language relatively friendly to humans. It can be expressed in letters, numbers, words. Values may require special forms, wherein the form translates into directions. Which gets us to the point: The language in which a program is written is not actionable by a computer. Action requires that the code (which is why it is called source code) be assembled, compiled, or interpreted into machine language (machine code). The machine code is put into production libraries. The source code used to create the machine code is supposed to be filed away so that the machine code can be replaced if it gets accidentally destroyed or corrupted. In an ideal situation, the source and machine code are kept at the same level. Needless to say, however, the ideal situation is rare indeed. The older the machine code, the more likely that its source code will become corrupted (resulting from changes made but not put into production, source code that is lost and an old version brought up from archives, or source code that is simply misplaced and nobody realizes it). Unless you can recompile (assemble or interpret) the code and fully test it, it is unlikely that you can spot any obvious problems until it is run in production. And because changes are incremental, the differences can be very subtle.
If there are inconsistencies between what is being run today and the versions that were saved in 1992, for example, your designated troubleshooter is going to have to spend time re-creating the changes that have taken place between the versions. In addition, lost programs and code will have to be re-created or restored-if possible. At this late date, you may have to buy software packages to replace lost code-another expense.
The Cost of the Update
The first order of business in estimating your code update/ reconstruction cost is to determine how many lines of code you must account for. If you are able to locate all your code, you will be relieved to know that it is possible to obtain line counts using the computer. Source code is usually stored in libraries on the computer. Production versions of the machine language are in runtime or object libraries. The names of these programs can be matched to the names on the members of the source libraries. This allows you to determine which source code modules are in use. Other modules are not shown in the object libraries because they are linked or included during compilation, assembly, or interpretation. To find which of these are in use, it is possible to match the source library names found to the link libraries. A similar operation is used to find modules brought together by interpreters, but the method varies by product.
While you will see forecasts of costs from $. 60 to $1.70 per line of code, this is an aggregate estimate for the entire code portfolio, including vendor-supplied code and control language code. Industry estimates for the cost of updating individual programs and applications (a group of programs with a single business purpose) of course vary significantly-from absolutely nothing to as much as $4.50 per line of code. Individual programs may not require any changes since they do not involve date processes. Many manufacturing companies use an artificial date that cycles every 20 or 30 years. These systems do not require many changes. Remember, we are talking about the wide variability in the cost of changing individual programs and applications-not the entire portfolio. The Department of Defense, for example, estimates that some of its code will cost up to $8.05 per line to change. The industrywide average is probably somewhere around $1.50 per line. Naturally, there is economy in scale of operation, so smaller enterprises will probably have to pay as little as $. 50 or as much as $2.50 per line. Complexity is a critical factor: Those applications that interact with a lot of other applications or that were written in arcane languages are more difficult to change (the Department of Defense estimate reflects costs for JOVIAL, hardly a popular computer language). If you want a rule of thumb to determine where you stand in these ranges, consider the following six attributes in the order presented:
1. Available staff knowledge of the application
2. Amount of planning prior to update
3. Capability of project management and level of enterprise awareness
4. Tools and methods that can be employed
5. Complexity of the applications
6. Visibility and risk associated with the applications
The ability of companies to accurately forecast costs has declined over the last two years. The advent of new tools, conversion factories, and the rapidly escalating wages of technical staff have complicated the estimating process. Remediation tools, software products that automate coding changes, often perform some testing for major programming languages (e. g., COBOL, PL/ I, Natural, RPG, even MS Excel) in addition to performing program changes.
Many companies have created factories where a firm can send its code and have it altered using tools. The cost of the process is often impacted by the site of the factory. Many have been established in India, the Philippines, Canada, Ireland, Barbados, and other locations where telecommunications links them to their customers and lower wages of local workforces can offset some of the manual labor costs.
Wages are increasing dramatically for programmers of many skills. The salaries of COBOL programmers are said to be increasing 7 percent per quarter in the United States as of the beginning of 1998. The average is no doubt influenced substantially by the New York job market where programmers' salaries are said to be rising by 6 percent each month. This is not limited to COBOL programmers. Many companies are taking a replacement solution.
They are competing for programmers who are skilled in applications such as SAP's R3, Oracle, PeopleSoft, C++, and Java. Even in India, there are shortages of COBOL programmers because those that know the language would much rather be working on new systems or with new languages promising career growth after the Year 2000 problem is resolved.
Because many enterprises have several hundred million lines of code, their costs to fix this problem will run into millions of dollars-most will be spent in 1999. If, for instance, your programming department staff consists of 40 people, they are probably supporting about 4 to 6 million lines of code. Using an increasing average cost of $100,000 per person-year, those 4 to 6 million lines of code will take about 40 to 60 person-years and $2 to $3 million in expenses to fix. In other words, the Year 2000 problem is your first, second, third, fourth, and fifth priority.
Let's suppose your company or agency has 10 million lines of code on your computer system (this is not an uncommon amount for a large firm or govern-mental institution). The cost may rise 20 to 30 percent over that of the firm in the previous example. The more code you have, the more money per line you're probably going to spend, because all of it no doubt interacts with every-thing else. Thus, when somebody changes one line, it will impact many more something elses, and more changes will have to be made to make it work (and don't forget, you still have to keep your customers happy while this repair work is going on).
What will the repair cost be? It is not easy to get reliable estimates. The Nuclear Regulatory Commission estimated that the 55 utilities operating 105 reactors in the United States would spend $3 million to $10 million each on the Year 2000 problem. This was promptly disputed by the Edison Electric Institute who estimated that the cost to a utility would range from $10 million to $100 million each. These costs include everything from code repair to replacing security and process control systems.
Counting Other Costs
Don't be misled by the preceding discussion into thinking, as so many have, that the Year 2000 problem is only a budget issue and that you will deal with it when you can finesse the dollars to do so. It is not only a budget issue; it is a scheduling problem, a skill problem, a resource problem, a testing problem, a management problem, and, most important, a time problem. Simply put, we are out of time.
Many applications will not wait until January 1, 2000, to fail. Already systems have failed as their look-ahead requirement has asked them to process date data in the year 2000. At the end of 1998, many more systems are likely to fail as they encounter processes that treat the year 99 as a special situation. These applications may start to reject valid data or treat the data as expired.
Not only are users concerned with the number of working days left between now and the year 2000, but they are also concerned with the number of week-ends. Applications are typically installed over weekends to allow time to change data and program linkages and verify that everything was installed as planned. With the number of weekends decreasing, the complexity of implementing changed applications increases. This increases the probability of errors. It is more likely that mistakes will occur that will not be discovered until later-much later. Some of those mistakes may have catastrophic results.
The costs of fixing embedded systems may add appreciably to the total Year 2000 outlay. On May 21, 1998, the Seattle Post Intelligencer reported that the Seattle Port Authority approved a budget of $4.7 million to fix code and embedded systems. The article went on to explain that an additional $12.5 mil-lion was required to replace a security system that was also subject to failure, but was too old to fix. The Kansas City Star reported on June 8, 1998, that John-son County expected to spend $17.2 million on the Year 2000 problem of which $8.2 million would be spent on the sewer system which has automated controls at critical points.
The embedded chip problem is a problem of numbers. While the percentage of these chips that process date and time data is small, only 2- 3 percent, the numbers are huge. With an estimated 6 billion chips produced in the United States alone in 1997, it means that there were nearly 100 million chips with possible date problems created in one year. These types of chips have been created in large quantities since 1975. Since it is prudent to test them all, it creates a problem of enormous magnitude for any organization.
Again, your computer-related costs are controllable. You decide what and when you are going to change. You may decide to replace the system instead of updating it. You can buy hardware as well as software and qualify for capitalizing the cost, stretching the impact on profits over the coming years. You have choices to make, but the decisions are yours.
The uncontrollable business practices costs will depend on the nature of your enterprise. For example:
If you have not yet started addressing Year 2000 issues, your choices will have to be hard-lined and costs will be more difficult to control. You will probably be limited to fixing only what must be fixed, not everything that needs to be fixed.
Tick, Tick, Tock
The longer you wait, the greater the risk to your enterprise and the greater the cost to alleviate that risk. Programmer repair costs mount daily with the ticking of the millennial clock. The competition for qualified people in this area is already fierce. Many consulting firms engaged in the Year 2000 update are already raiding each other for experienced technicians and managers. Many of the larger firms are limiting the number of jobs they are taking on. Some will only take contracts with businesses that promise continuing work after the year 2000. Some accounting firms and large consulting companies, afraid of litigation risks, are curtailing their Year 2000 programs. This trend will continue to drive up costs. Reports of the number of firms who charge to make a sales call are increasing.
Most organizations are already unable to finish the work with available staff. Following is a review of a typical case of an organization with 15 million lines of mainframe code and 2 million lines of code on other platforms. Assume that the planning started on January 2, 1997, and the final system is to be migrated by December 31, 1998. Here's a breakdown of the process:
Time: January-March 1997 Phase: Sizing Resources: 12 staff months
Time: January-June 1997 Phase: Planning Resources: 12 staff months
Time: April-July 1997 Phase: Pilots Resources: 50 staff months
Time: July 1997-December 1998 Phase: Update Resources: 1,800 staff months
Beginning in 1997, the overlapping of phase activities becomes necessary. It is important to be finished by the end of 1998 to allow the changes made to be run in production through daily, weekly, monthly, quarterly, and year-end cycles during 1999. The crucial period of this plan is the update. During those 18 months, the enterprise will have to commit 100 people to the task. Not only does it not have the people, but even if it found them, it does not have the facilities and equipment to allow them to perform the work.
If the organization was not already into the update process by July 1997, the time line is reduced significantly, and the resource requirement changes dramatically. A delay of three months requires the addition of 20 people. For every process that is delayed, the impact may be the loss of several precious months. If the enterprise cannot find or devote those resources, its price may be the collapse of many applications. Bottom line: If you don't meet the deadline, the deadline will meet you. The enterprise is already in jeopardy.
Many desperate managers who realize that they won't be able to fix their applications in time decide to perform wholesale replacements using one of the enterprise resource-planning systems. Those that haven't started with systems replacements by July 1998 will find themselves working against industry experience that indicates a one-and-a-half to two-year implementation cycle once the product is selected. The shortage of skilled people to assist with that implementation is also increasing as companies already engaged in implementation find their schedules slipping and their risks mounting.
What is required is a rethinking of what applications and process control equipment is necessary to the survival of the enterprise. This process is called triage and is discussed later. The principal mode of operation whether the fix process has or has not been started is risk management. The focus is on short-term workarounds or temporary fixes, abandoning some work, using people to make up for equipment that doesn't run, and creating liaisons with companies that will be able to help. For some it means finding a buyer while the business still has value.
Costs You Can't Control
Now it's time to tackle costs outside your immediate domain; those outside factors can bring down your enterprise, even if you do have all your internal applications upgraded and 2000-ready. Few companies are publishing the expenses they are incurring trying to manage the external factors that must be identified, contacted, tracked, and managed. There are no guidelines and no measurements that can be used to estimate these costs.
Look at these recent examples of what may happen because of society's technology dependence when 2000 comes:
It has become a practice in the Year 2000 industry to refer to computer-related suppliers and service organizations as vendors, and the balance as suppliers. The problem with vendors is that they are in the critical path to getting computer systems fixed for the year 2000. The first order of business is to alert your vendors to your needs. Begin by getting answers to the following questions immediately:
The following steps are recommended to establish control of the vendors (courtesy of Data Dimensions as reported in the Millennium Journal, volume II. I):
1. Centralize vendor management responsibility.
2. Set vendor policies for new acquisitions.
3. Determine whether changes are required for each purchased product.
4. Establish the event horizons for each product.
5. Identify the current vendor for each product.
6. Build a vendor database.
7. Determine contractual responsibility.
8. Contact the vendor for plans.
9. Plan implementation steps.
10. Communicate the vendor's and your own implementation plans to others who need to know.
One proactive manager of a testing laboratory in a client/ server environment found that he had 14 vendors of hardware and software products. Once he defined his needs for each vendor, it took him about two and a half years to achieve compliance. Specifically, it required individual meetings with each vendor to explain the problem. Then each vendor was asked to test its products and schedule the necessary changes. In some cases, the fix required reprogramming application software; in others, it also meant changing the data output. The biggest problem was in scheduling which changes would be implemented. Certain vendors finished before others, and in some cases the changes didn't work and the vendors had to repair them.
Unfortunately, if you are a large corporation you might have 10,000 vendors for which to define requirements and track for compliance. But regardless of the size of your enterprise, there are four categories of suppliers that you must be concerned about:
Application software packages and programs you bought from vendors present several potential problems.
Closed for business. The nature of the fast-paced, ever changing computer industry has resulted in companies going in and out of business before you have a chance to add their cards to your Rolodex. Others will bite the dust as a result of the Year 2000 problem. Thus, you may find that the vendor from whom you bought your software is no longer in business or available to help with your transition.
Maintenance contract issues. If you stopped paying for maintenance for a number of the products you are still running, you may have to reinstate the contract to obtain the upgrades. And be aware that some vendors will charge several years' maintenance fees. You may also have difficulty integrating new features or functions that were added. And even if you kept your maintenance contract current, you may find that your vendor does not have the knowledge or staff to fix your code.
Not my problem. Expect a number of vendors to simply declare your products as unsupported and stop charging maintenance fees. Of course, this leaves you holding nothing. If you are lucky, the vendor may be able to provide the source code so your staff can fix it.
When is soon enough? If your vendors tell you they plan to fix the code, the first question to ask is, "When?" The second question is, "Will it coincide with my needs?" That second question will most likely have two answers, one determined by how much internally developed code must be changed because of the vendor's revisions. The second answer depends on how you're using dates within the system. You may need the changes earlier than the vendor can provide them.
Computer Hardware and Systems Software
Hardware vendors provide the systems software that the computer uses to run, and this software is full of dates. You will be relieved to know that most systems software is either already compliant or in the process of being made so, although some of these fixes are not scheduled to be implemented until 1999.
Unfortunately, as with some application software vendors, some equipment vendors, too, may declare their software as unsupported, meaning that the vendor will not make the changes. Usually this is the case when a vendor does not have enough customers to justify the expense.
In many cases, the hardware issue is complicated because companies have chosen to stay with an older system to avoid the cost of upgrading, and there-fore any Year 2000 changes will be to a version that they are unequipped to install. According to the Portland Oregonian, in early August 1996, an untested computer system went into service during the Department of Motor Vehicles' busiest season. The manager resigned amid an uproar following her estimate that it would cost $75 million for the new computer system (estimates are now running closer to $123 million), which was originally estimated at $48 million. Ironically, one of the reasons testing may have been put on the back burner by the agency was because of workforce reductions that were made in anticipation of labor savings from the new computer system.
The most well known problem to date, which is widely regarded as the first of many anticipated lawsuits, happened in August 1997. The owners of the Warren, Michigan, Produce Palace International filed suits against TEC America (the makers of the cash machines) and a local vendor, All American Cash Register (the installers of the machines), when the entire network of cash registers failed. This was due to credit cards reading 00. Although customers were able to pay with checks and cash, many left irritated by the long lines and constant failure of the registers. A spokesperson for TEC America blame