Publication Date: September 20, 1996

Related article - It Is Already 2000 at Bank of Boston

The Doomsday Date

By Sue Mellen

It's the stuff B-grade science fiction films are made of: The new year dawns over an ultra-modern society, but civilization is cast into a second Dark Ages as computerized systems all over the world crash or malfunction. Governments, multinational corporations, banks and financial markets come to a screeching halt. Faulty air traffic control systems leave jets sitting shoulder-to-shoulder on runways, while colorless traffic lights stare blindly over empty roadways and trains sit in yards waiting for routing advice that will never come. It's The Computer Code That Ate Tokyo, airing Sunday at 3 a.m. on your local UHF station.

It may be comforting to think of the above scenario as pure celluloid fantasy, but according to experts who have studied the Year 2000 problem, the plot rings frighteningly true. If computer code worldwide is not made "millennium compliant" by the end of 1999, computer-dependent activities (and that’s just about everything in civilized, technological societies) will be at risk, some analysts say.

Both Ontario's Peter de Jager, one of the early prophets to study the Year 2000 issue, and Ken Orr, who focuses on technology and change at The Ken Orr Institute in Topeka, Kan., believe that it is 11:55 p.m. and the Doomsday Clock is ticking. Before the end of this century, software applications all over the world will fail or produce erroneous results because their logic cannot deal with the transition from 1999 to 2000; or, to be more accurate, the transition from 99 to 00 in the two-digit fields used to store year dates. When a computer performs a calculation using a two-digit date for '00 or beyond, the result is a string of faulty conclusions that can confound and overload the embattled CPU.

"Imagine what the world would be like with no computers, keeping in mind that a computer is no good if it's running garbage. Every facet of our lives would be affected. I like to pose this problem: Suppose you are in New York and your spouse is in California when the computers fail. How long do you think it will take to get to the West Coast, remembering that planes will be grounded? Invariably, people answer, 'I'll just drive, so it will take me about a week.' Then I ask where they'll get a second tank of gas. Gas distributors will be disabled. In the end, you would have to walk to California. It would take you about two years," says de Jager.

De Jager believes that, left unsolved, the Year 2000 problem could lead to an economic catastrophe far worse than the Great Depression. He points out that the Depression of the 1930s was based largely on a lack of confidence in the stock market and solved by putting people to work. "In this case, there will be no work," he predicts.

The Scarlett O'Hara Syndrome

Orr calls the Year 2000 dilemma "the world’s simplest problem." (Simple to understand, not necessarily to solve.) In the '50s and '60s, when data was stored on punched cards, storage was extremely limited and expensive. Consequently, almost any method capable of saving space gained universal favor. A seemingly harmless shortcut was to store dates in computer applications in two-digit form.

In subsequent decades, many card-based systems were transferred to tape or disk, bringing the two-digit methodology into the next developmental stage. Capers Jones, chairman of Software Productivity Research, Inc. (SPR) in Burlington, Mass., expresses the problem very colorfully when he says, "...It is well known that poisons such as arsenic accumulate slowly in the body. Tiny doses, each harmless in itself, can slowly accumulate until the victim perishes. In some ways, the Year 2000 software problem resembles the slow accumulation of arsenic. For many years, software applications have been built with two-digit field year dates. Year by year these two-digit fields have been accumulating in software packages all over the world."

According to de Jager, the problem is rooted in our own inherent laziness and a speech pattern that chops off the first two digits of a year. "How often do we say 'the 1990s'? Never! We always say 'the '90s.' It was the most natural thing in the world for early programmers to store data that way."

Then, he says, it was the Scarlett O'Hara-"I’ll think about that tomorrow"-syndrome that perpetuated the problem.

"Back in the '70s, there were a lot of young programmers right out of college storing this data. They weren’t thinking about what was going to happen 30 years down the road. Who knew what they'd be doing at that point? Then, in the '80s, the problem was still 20 years away. Why worry about a problem that’s two decades down the line?"

Then the '90s, hit, which would seem to have been the logical time to deal with the problem looming on the horizon. But, as de Jager points out, through the early years of this decade the industry was being buffeted by a major recession, thrusting programmers and engineers into the world of the unemployed.

"Under those conditions, can you imagine going to your manager and saying, 'We need to spend $50 million and there won’t be any additional revenue'? It just wouldn't happen. Of course, the point everyone missed is that the company probably won't be in business unless it spends the money necessary to solve the problem," de Jager says.

Another contributing factor, de Jager and Orr say, was the myth that mainframes—the original repositories of the problem—would disappear from the corporate scene, taking the Year 2000 predicament with them. Not only are mainframes still with us, the two-digit system has insinuated its way into applications imbedded in the client/servers and PCs that are the backbone of American business.

The Right Time to Get Started? Right Now

Time is up. Companies projecting rates into the next century—banks and credit card companies are good examples—have already sampled the bitter taste of the Year 2000 problem as their systems balk at making the necessary calculations. And, to borrow the vernacular, "You ain't seen nothin' yet!"

Still, according to de Jager, 65 percent of businesses have done nothing about the problem. One reason is the astronomical price tag the project will carry. Estimates for solving the problem run anywhere from $200 billion to $1.6 trillion, with costs possibly reaching $500 million for a single Fortune 500 company. And the current tight employment market in the industry presents another problem. Teams of programmers will have to run vast amounts of code to weed out problems and prepare applications for the next century. Will the necessary talent be there?

"I think it will be easy enough to find the people we need to work on project teams. It may be a little tougher, in the current market, to find project leaders. All the guys who can fix this are already pretty busy. But if you've got a good programmer working on another project, you should pull him immediately to concentrate on this. This should be your first, second, third, fourth and fifth priority. Otherwise, you won't be in business in the year 2000," de Jager says.

Both Orr and de Jager suggest assessing your whole system, then "triaging," or prioritizing, the project by concentrating on your most mission-critical applications before the storm hits with full force. As time permits, applications throughout the corporate system can be scanned and modified. Many companies are considering the construction of specialized facilities to test for and correct Year 2000 glitches in their systems, says Orr.

Believe it or not, there is an up side to all of this. As a result of making their systems millennium-proof, companies will gain a much better understanding of, and control over, their computer systems.

And, as Capers Jones of SPR points out, the industry will be better prepared to deal with other problems certain to grow out of early programmers' penchant for abbreviation. "The same tools and methods being applied to the Year 2000 problem can also be applied to similar topics. So software created after the end of the 20th century should be better structured and more robust than software typically created before the end of the century," he says.

Sue Mellen writes from Tyngsboro, Mass.

---

Ken Orr and Peter de Jager are featured speakers at DCI's Year 2000 Issues & Answers Conference. You can see more of de Jager's thoughts on the date-change issue in his article Systemic Triage in the DCI archive of articles.

Related article: It Is Already 2000 at Bank of Boston

---