the query column

Time to Press the Panic Button!

Computer systems are a lot like cities. Older sections become rundown and outdated, but remain functional. They continue to exist while being intertwined with the new, squeaky-clean steel towers built down the street.

by Thomas Caldwell

       The old adage of "If it ain't broke, don't fix it!" is applicable to New York's subway system or San Francisco's cable cars - and also to the old mainframes that are still performing mundane tasks for an organization in a basement someplace. But if San Francisco lost its cable cars, or even New York its subways, the city would still function. But if an enterprise loses its computers....

       Recently, Computing Japan carried an article about the Year 2000 Problem [See "2000 Will Be Too Late," June, page 53.-Ed.] - that is, the inability of computer hardware and software to handle the date changeover from December 31, 1999, to January 1, 2000. Lots of people are talking about the Year 2000 Problem, but unfortunately most Japanese information systems managers are not doing anything about it. It is, frankly, a ticking bomb that will go off in just 28 months. The time for fear and terror - as well as opportunity - is now.

       In short, many companies and government institutions are not going to make it. A significant number of companies have been squandering their time, denying that the danger is real. But disaster is approaching, one that you can prepare for and - if you are smart - cash in on.

       Norman Sess and Howard Santamore are two Japan-wise computer engineers who head up AV Engineering, a consultancy that works with companies to seek out and solve potential Year 2000 problems. Sess reports that while many companies are aware of the problem, few seem to have grasped the potential consequences or even how widespread in Japan it really is. He recommends that companies should get everybody involved in the solution, not just the systems people. "Who knows more about how the program is used [than] the person using it?" This means everybody in an organization who uses a computer, not just the engineers.

       Santamore adds that the outsourcing which corporations have gotten hooked on over the past decade could come back to haunt them. "Suppose you have been outsourcing. You have a good vendor, you're happy with them, they give you excellent service. But a year or two from now, they're going to be very busy. How much time are they going to have to help you with this problem?"

       Although growing numbers of software packages are being sold to find and assist in fixing Year 2000 compliance problems, this may not be enough. "None of the software I have seen up to this time gives 100% guarantees," says Sess. Almost all such software is full of disclaimers: the maker guarantees nothing. If it doesn't do what it is supposed to, that is just too bad.

       What can you do? Well, if you are a corporate executive:

  • Immediately begin an awareness program. Not some silly "gee guys, we better do something" vagueness. Start talking about the end of civilization - your corporate civilization.

  • Start collecting every bit of documentation on the systems and source code in use within your company. Call up former employees, and bring them in to reminisce about the good old days (back in the '80s, before the company fired them to hire some goofy PC jock). They might remember something of value. Far fewer software and hardware systems are documented than most CEOs (and shareholders) would ever believe.

  • Hire good programmers, and keep them. The same COBOL programmers (more systems in Japan still run on COBOL than you might imagine) who were laughed at and canned not so long ago could turn out to be the most highly paid programmers on the planet in a few months' time. The same goes for assembly language experts. There are still many, many business critical computer systems that operate using such "outdated" languages, and very few new programmers are learning them.

       If you are an innocent civilian:

  • Do not plan on traveling between September 9, 1999 (coded as 9999, which is a great way to end a program), and for a while after the millennium. Something is bound to screw up somewhere affecting vehicles that have wings, rails, or wheels.

  • Keep a significant amount of cash on-hand, and store your paper bank records in a very safe place. Your credit cards may not work for a while (some are already having problems with post-1999 expiration dates), so you could need cash to survive.

  • Try not to be in a hospital having major surgery then. Lots of hospitals in Japan run on very old systems, and you could find yourself being misdiagnosed or misoperated on (something that happens often enough while the computers are working).

       And if you are in the computer industry (and want to get rich):

  • Learn COBOL.
  • Learn COBOL.
  • Learn COBOL.

       Fixing the world's computers before the end of the millennium will be expensive, but it is essential. Finding a solution to the Year 2000 Problem is the ultimate project deadline; there will be no extensions.

       For corporations that don't take the problem seriously, Santamore offers an ominous warning. "Pay the programmers now, or pay the lawyers after the year 2000."

You can reach Thomas Caldwell at caldwell@gol.com.

For further information

Year 2000 "war stories":
http://www. isquare.com/y2kstory.htm
AV Engineering (phone 0120-21-4212;
http://www.click.or.jp/~y2000/


Back to the table of contents