Facebook Twitter

Millennium problem a looming nightmare

SHARE Millennium problem a looming nightmare

I have never been one to embrace prophets of doom. I have never stood on a hilltop waiting for a return of deity. I ignore those who predict coming peril from global warming or unwashed cranberries; nevertheless, I am beginning to worry about the year 2000.

No, I do not have inside information on the Second Coming. What I have, however is the copy of a paper by a professor I met at Harvard recently.Dr. Paul B. Clark and I were having lunch during a teacher's training session held in Cambridge when he shared with me some research that made me nearly choked on my apple strudel.

He said, according to his research, that American corporations may have to spend more than $60 billion preventing and cleaning up difficulties caused by what has become known as the millennium problem.

Clark said the alternative to facing the problem may be going out of business.

How did this threatening economic problem ever get started? Evidently, it was a "two bit" or two bytes decision, and it was the right decision at the time. Since dates are one of the most commonly stored data elements on computers, two bytes saved here and there soon became megabytes, according to Clark.

Therefore, most programmers left off the first two digits of the century; that is in most computers 1977 just became 77.

The situation that will now occur in less than three years is that the computer date Jan. 1, 2000, will become Jan. 1, 00, which instead of being seconds after Dec. 31, 1999, will become 99 years before. If you are, say, on a long-distance phone call, your telephone carrier, unless their computers are fixed, may credit you with a 99-year call.

All date dependent systems are at risk. Here are some examples of what it can effect; interest calculations, aging of accounts receivable, payroll systems, amortization and investment annuity calculations, and countless others, according to Clark.

If this is such a big problem, why hasn't somebody done something about it earlier? Perhaps there are at least three reasons; first, organizational procrastination.

Clark explained, "Who wants to be the bearer of the bad news that millions of corporate profits will need to be spent now on solving a problem that won't generate one dime of revenue."

Unfortunately, as in the case of most problems, denial will lead to a compounding of the problem.

Ignorance of the problem was perhaps a second reason for not doing something about the issue; however, with hundreds of articles appearing in industry newsletters in 1995 and 1996, that is no longer an acceptable excuse. In 1997, hundreds more articles appear each quarter.

Currently, according to Clark, there is also an Internet home page dedicated to the problem. Interested parties can access the "Year 2000 Information Center at (www.year2000.com/hist.html). In a recent three-month period, more than 270,000 visited the page.

I am certain the third reason little has been done about this catastrophic problem is corporations, especially public companies, don't want to spend dollars to solve problems that won't bring a multiple to the bottom line.

Clark spells out the magnitude of the issue. He states a mid-sized corporation may have 10 mission critical date-dependent software applications. If we assume that each application has, on average 500 program modules, let us further optimistically assume that it takes only one day to modify each module to be year 2000 compliant. Without any testing time, this results in 7,500 working days to fix the modules. Unfortunately, there are less than 800 working days before the clock strikes midnight.

Another problem is where does a company find 15 skilled system analysts and programmers to even understand the problem, let alone have the skills to fix it.

Of course, one midsize company looking for skilled people might find them, but multiply that by all companies with a similar problem, and you have a nation vying for the limited pool of available system analysts and programmers.

If you are like me, you are sure all your personal computers in your company were "fixed" at the time of manufacturing. Then I ask, are we really sure? Also, the computer might be problem free, but what about the date dependent software?

I changed the date on my clock in my computer to Dec. 31, 1999, at 11:55 p.m. I turned the computer off and came back about a hour later to see what had happened. The date had changed automatically. That's the good news. The bad news, it now showed the date as Jan. 1, 1980. Now what do I do?

I almost wish now that I had not even gone to the Harvard conference. At least then I wouldn't feel as if I was using a time bomb every time I turn on my computer. And I wouldn't be hearing that darn awful tick, tick, tick . . . either.