The High Cost of Missing Two Missing DigitsX By Bart Eisenberg

It is a problem that, on the surface, is so simple to understand that you first wonder what all the fuss is about. And yet, it is a problem so complex in its ramifications that the solution will cost billions of dollars to implement. Some have called it a ticking time bomb, others see it as an opportunity to make a lot of cash quickly. It is called the Year 2000 Problem, and like its name suggests, it is one of those things that could happen only once in a millenium.

The Year 2000 Problem is easy to explain. Back in the old days, the 1960s, when disk storage space was at a premium, programmers reduced the size of database records by shortening the year field from four digits to two, so that, for example, the year 1975 is encoded as "75." It's safe to assume that most programmers realized--even if they thought about it for a minute--that this system would only serve them well through the year 1999. It also safe to assume that some programmers pointed this fact out to their bosses. But in the 1960s and 1970s, the year 2000 still seemed like another era. After all, by the year 2001, according to Arthur C. Clark and Stanley Kubrick, men would have base camps on the moon and computers would hold intelligent conversations, read lips, and be capable of murder.

The truth is that until very recently, the year 2000 seemed so far off that it was not worth thinking about over the course of an ordinary work week. Now it is seen as a ticking time bomb. At one Web site, sponsored by EDS R&D, the remaining days, hours, minutes, and seconds tick off in realtime. (At this writing there are 10,066 days, 15 hours, 41 minutes and 21 seconds.)

And so, here we are with just three years left to go and suddenly the Year 2000 Problem has become a dilemma of major proportions. In the United States the problem gained national attention when a subcommittee of the House of Representatives held hearings on the subject. Gartner Group, a large research organization, told the elected representatives that the problem would cost between $300 billion and $600 billion worldwide to fix, and that 30 percent of all computer applications would not be fixed by the end of 1999. Others put the price much higher.

Kevin Schick, a research director for the Gartner Group, has written that "the Year 2000 date change poses one of the most significant challenges ever faced by the IT industry and will have an enormous impact on business applications, package solutions and systems software, even putting some companies at risk in their business. The bottom line is the year 2000 virus is the most devastating virus ever to infect the world's business and IT system." According to Schick, "the alternative to addressing the year 2000 will be going out of business."

James A. Jones, director of the Year 2000 Group, has characterized it as "one of the most interesting challenges since the dawn of the computer age. It is potentially the largest project the IS department has ever attempted. It has life-threatening implications for the business. It has an absolute immovable deadline. It is a significant, unplanned, out-of-budget expense, and it has no sponsor."

"There are some organizations so literally computer dependent that, they will NOT be able to get that cash flow moving even if they hire 100 accounting clerks. What invoices do you pay? What do you bill? EVERYTHING is in the computer.... The clock struck January 1, 2000 and the computer had a stroke," writes Peter de Jager, a long-time observer of the problem. As he points out, all you have to do to get an idea of the gravity of the situation is to enter 00 on a typical data input screen. Most likely what you'll get, if the program is doing its job, is a data exception--a notice of an invalid entry. That would be a good outcome. The more problematic scenario is that the 00 is accepted as a valid entry, meaning for all intents and purposes, that the record is dated almost 1000 years ago.

Centered around COBOL

The Year 2000 problem is primarily, though not exclusively, a mainframe problem centered around COBOL code--quite simply because mainframes have been around the longest and COBOL, the language of corporate programming, produces applications in which ordering of dates is essential. What nobody really saw- -or saw clearly enough to really matter--is that legacy code has its own momentum. A company that has poured perhaps millions of dollars into its development and maintenance of an internal general accounting program will do almost anything imaginable to avoid having to rewrite that code from scratch. This code has been maintained for so long, by so many developers that it resembles an archeological relic--you can see what it is but you have no idea how it got there. Not only do the programmers on staff not have first-hand knowledge of these problems, but the developers who did are now dead-- and the people *they* hired are retired.

If the Year 2000 Problem centers around COBOL, just how big of a problem is that? Some estimate that there are 180 billion lines of COBOL code in existence and about 900,000 COBOL programmers maintaining it. These applications, although old, often come under the category of "mission critical," meaning that when they stop, the company stops. It has to do with invoices being paid and invoices being issued, and employees being paid, records being kept, customers served, and products tracked. How many COBOL programmers it will take to fix the problem is anyone's guess, but the number is not inconsequential. Indeed, some versions of COBOL don't even support a 4-digit year field.

But while COBOL may be the epicenter, the problem extends to many languages, including applications written in programming languages, and some language versions that have been all but abandoned.

Another complicating factor--one that plagues virtually all software developers--is that application code is modular. That means an application that has been purged of the Year 2000 Problem can still run into difficulties if it happens to call an additional module where the problem still exists.

PC problems less threatening

Because it is relatively new, the personal computer and its applications are less vulnerable to the Year 2000 Problem. A Microsoft representative told the congressional committee that Microsoft's products are Year 2000 ready, that it anticipated the problem even with its initial work on MS-DOS, and that all of its operating systems, including MS-DOS, Windows 3.x, Windows 95, and Windows NT, can handle files created up to the year 2108--by which time Bill Gates will be retired. For PC users, of course, the problem may still arise when connecting to another system in which the problem hasn't been corrected.

Microsoft's Win32 API was designed to handle dates up to the year 2099, while the company's databaseapplications, including Visual FoxPro and Microsoft SQL Server, can handle four digit dates up to the year 9999. The one Microsoft application vulnerable to the Year 2000 Problem is the 1995 version of Microsoft Access. The company says that the 1997 version will correct it. Microsoft has also made some of its end-user applications "Year 2000 savvy." Enter "01" and Excel will assume you are referring to 2001, not 1901. You can override this default by entering the entire four-digit year.

How to fix the problem

Despite its vast dimensions, the Year 2000 Problem is hardly incurable. For most companies, it is a matter of identifying where the problem resides, correcting the code, and verifying the results. There is also the matter of correcting existing data. In some cases, these corrections can be done manually. In others, it can be automated. And in most cases, it will be a combination of both. Some large software vendors are developing their own automation tools and the dilemma they face is in making certain they don't oversell this technology to their customers. The United States, especially, is a litigious society: people sue for all kinds of reasons, legitimate and not. That means that any company who thinks it has purged its software of the Year 2000 Problem does not want to be in a position of having to absolutely guarantee it. One slip somewhere in the code, and the lawyers will descend.

The most obvious fix for the problem is to convert two digit years into four digits. But for some companies, that's a daunting problem. In some cases, the task is so daunting that programmers are looking for ways to work around the problem. As Gene Lynd, of the Defense Logistics Agency, pointed out about his own shop, "it would take until the year 3000 to change one file at a time. But if you were to do many at once, the effect would cascade throughout the system (and beyond). All programs and files affected would have to be deployed at the same time....we are therefore working on support for a program-logic based solution." His group has done this by creating a routine that infers the century in performing calculations on two digit years.It does this by creating an artificial "forward century" as well as a counterpart "backwards century"--both accomplished by adding 25 to the current four digit year and considering only the last two digits. Hence, the year 2000 reads as 25, while the year 1997 reads as 22. Obviously, this is not a permanent solution, but it does buy a quarter of a century.

A racket?

Not everyone thinks the Year 2000 is all that big a problem, rather, that it has been exaggerated largely by people who see the opportunity to make money.

Writing in the publication American Programmer, consultant Nicholas Zvegintzov argues that what he calls "the Year 2000 racketeers" are treating this problem out of all proportion to its real danger. In their panic, they are buying software tools, attending conferences, and purchasing the services of third-party consultants to help bail them out of the mess. They are dealing with the problem as if it were the problem of the century, when it is in fact "a simple example of problems that they have to solve now and for ever."

He points out that the Year 2000 problem is but one instance of a broader problem software problem of not allocating sufficient digits--or restricting what digits a field will accept. The North American telephone system, for example, once used three-digit area codes in which the middle digit was proscribed as a zero or a one. But with the exploding demand for new incoming lines (for fax machines, modems, and additional telephones), that restriction had to be ended-- resulting in considerable reprogramming of telephone switching equipment. Zvegintzov says that the U.S. government is running out of Social Security Numbers--the number that every American must have in order to work. Similar problems, according to Zvegintzov, resulted in The Bank of New York losing track of $25 billion worth of government securities and to a timing error in a Patriot missile launcher that resulted in a Scud missile killing U.S. Army personnel in Saudi Arabia. All of this, he contends, is relatively easy to anticipate and easy to solve.

"Dealing with the Year 2000 problem is a simple software task. It is clear when the problem arises (at the end of the century). It is clear what it will do (confuse calculations performed with dates). The places where the problem arises are easy to find in software code (places where dates and times are represented and manipulated, places where fields of two decimal digit are used). The corrective action to be taken is straightforward (substitute a time and date representation with a longer horizon). Solving the Year 2000 problem is an exercise for the software novice.

"Most real world software problems are much harder; they are problems in which neither the context, the symptoms, the evidence, or the treatment are so plain. If an organization cannot handle the Year 2000 problem, it is a dangerous organization indeed; avoid it!"

The problem with this analysis is that--with software development, the best estimates are usually overly optimistic. Delivery dates are later than expected; the bugs are greater. Unforeseen problems always seem to intrude, and people who should know better sometimes don't. Stupidity happens. Knowing this, critics have been quick to say that current cost estimates are, if anything, understated. As soon as the U.S. government suggested it would cost some $2.3 billion just to fix its own software, Harris Miller, president of the Information Technology Association of America called the estimate "ridiculously low."

"I've been at this for six years, and as much as I know about the problem, there are still times where I ask myself whether I have overestimated it," said Peter De Jager. "Maybe it will be a week of chaos as people try and patch this thing, and that will be it. And then I remember that no, a certain company has five terabytes of database that needs to be fixed, that some of the documentation is missing, or that we don't have the source code. Then I wake up and say no--there is no simple patch.

"But this is a unique situation where everybody in the industry who talks about the Year 2000 problem hopes to God that they are wrong. We all hope that Zvegintzov is right."

An Interview with Peter De Jager: The Y2000 Problem Apostle

Peter De Jager is one of the most vocal and visible authorities on the Year 2000 Problem. Based in Ontario, De Jager first wrote about the subject in 1993--well before most of the computer industry had given it a second thought. He has since testified before the U.S. House of Representatives' Science sub-committee hearings and is a special advisor to the UK Year 2000 Taskforce. With the year 2000 approaching, he now travels about 10,000 miles a week. He spoke to me by telephone from Johannesburg.

Is the Year 2000 Problem due to laziness or shortsightedness, or is it just an inevitable part of the human nature?

Mostly, it's human nature. The one big component of the problem is that it is literally an unbelievable problem. The notion that by leaving off two digits, major organizations now risk losing all computer functionality is unbelievable. And it has taken this long for people to finally understand that this is real and that there are consequences. That's human nature.

With some people it is stupidity. Some people should know better, especially now that IBM has came clean and says the problem is real, and after companies like British Telecom have started doing some major strategic decision making around this thing. Swedish Telephone Company has estimated it is going to cost them alone 2.3 billion Swedish Kroner, which is $300 million U.S. dollars.

When a company like that says they are going to spend that much money, they are not doing it because Peter De Jager or anybody else says there is a problem. They are doing it because there *is* a problem. So when you go to another company and they haven't yet started their inventory, you have to worry about their management ability.

Do you agree with the Gartner Group figures of the cost of the Year 2000 problem?

Their $600 billion high-end figure would fall to the low end of the industry estimates. At the high end is one for $1.6 trillion world wide. My guess is that it will fall somewhere between those two numbers.

>Nicholas Zvegintzov contends that the problem has been exaggerated and has become a consultant's racket. I assume you disagree with that.

Nicholas and I go back more than 10 years, and we are friends and have a tremendous amount of respect for each other. His point is focused purely from a technical aspect. He says this is nothing but a maintenance job. And he's right to a point. What he is leaving off is all the secondary and tertiary effects of this thing.

This is a unique problem. While I agree with his simple statement that this does not require brain surgery skills-- it's just fixing lines of code--The problem is bigger than anything we have ever attempted before. Most project managers have never dealt with a project larger than 10 years in size, and this thing is typically hundreds of years in size.

That's a paradox I've not been able to resolve. If it is just a matter of adding a couple of digits to a field, what's the big deal?

The big deal is the sheer size of it. We are not talking abut 10 million lines of code that are independent of each other. These are systems that are interdependent. The last 10 years we've been trying to integrate our systems. So what we have now is this huge pile of spaghetti.

So we think now of databases as having a data dictionary and everything being central and being easily corrected. Is the fact that this is mostly legacy code that has made this more difficult?

It is not just legacy code. That's a common misconception. Java 2.0 is not Year 2000 compliant. You can write C++ code that is not Year 2000 compliant. This notion that it is only the foolish, doddering old COBOL programmers is nonsense.

Is it mostly the foolish, doddering old COBOL programmers where the problem centers?

It is not mostly, but without a doubt, some of the major impact will be felt from those areas because it is the old COBOL code that is still running the world. People say Windows doesn't have a problem, or my Mac is fine. Well, so what? The global financial interchange system doesn't run on a Mac or on Windows. Your inventory program is not written for the Mac or a PC, nor can it be. These are mainframe-based, large transaction systems.

Microsoft declares itself as having almost a clean bill of health except for one version of Access. Is that your take as well, or are they going to run into problems because they are interrelated with other programs?

The problem with Microsoft is that they have a whole suite of products--and they are inconsistent. In some programs, if you type in 22, you get back a date of 1922. In another product, if you type in 22, it gives you 2022. Each product by itself is "Year 2000 compliant" but when you use the whole suite of tools together, and may be passing data from one program to the another, things can get real hairy.

The other thing to realize is that despite the immense wealth of Bill Gates, he still does not rule the world when it comes to PCs. There are a lot of 286s out there running old and mature accounting systems that, quite frankly, do the job. They might be owned by a farmer, a small businessman, or some mom and pop store. Their accounting software is not Year 2000 compliant, and their vendor will not come out with a 286 version that is compliant. They are going to come out with a Windows version--which forces this poor schmuck to go to a 486 or 586: all because some dumb company didn't write the code properly.

To what extent is this a global problem?

It is greater in the U.S. because the U.S. is more automated and technologically oriented than any other country. However, it is still a worldwide problem. We move data back and forth between countries. Everybody has PCs. We have embedded systems worldwide.

Japan scares me because we've heard nothing to indicate anything is being done in the Far East and in Japan.

Are you saying it hasn't taken place at a corporate level?

We have not heard it. Now just because I don't hear it on my Internet mail list does not mean the Japan is ignoring this. But the mail is large, and the articles about this are coming fast and furious. And we hear very little from Japan, and Japan is technologically oriented. They have access to the Internet, they write code, they build systems, they buy our products, and yet we don't hear anything from them.

So either they are fixing it quietly or you are predicting a disaster on Jan. 1, 2000.

They may be fixing it quietly--but that is not how this things gets fixed. The problem gets solved with noise, with a big media push that makes companies aware. But I haven't heard of any Japanese Year 2000 vendors. And I'm in a position where I should be hearing.

Are most companies tackling this on their own, or are they bringing in consultants? And what is the best approach?

This is where we sometimes get accused of creating this problem so the consultants benefit. This is a situation where you can do it on your own, but you are going to be reinventing the wheel, which is unnecessary. I see no shame in hiring a consultant. The reality is that if someone has been working on this for five or six years and made it their exclusive domain for a little while, they are going to know things that you are not going to know.

On the other hand, as Nicholas Zvegintzov points out, this is just maintenance, and you don't need any special guru to help you do that. And, in a sense I agree with that as well. It depends on how much your know your code.

But one of the realities is that most companies are taking six to 18 man-months just to answer the question "how much code do we have?" We've never had to ask that question before. Abraham Lincoln was once asked: "How long should a man's legs be?" His response was "Long enough to reach the ground." This is a very similar thing. How much code do you have? Enough to run the business. But now you have to answer that question and it takes six to 18 months to do it. Not everybody knows the answer. The world is not as organized as we would like to believe.

Sometimes, it sounds like the ballgame will be over on January 1, 2000. Either code will work, or it won't. Is it that cut and dry?

We won't be rid of the problem until around the year 2010. For the next decade we are going to be fixing the code that we didn't get around to fixing.