From PC Magazine,

September 1, 1998

 

 

It's Time to Act on Y2K

 

By Michael J. Miller

 

By now, you've undoubtedly heard a lot about the so-called "year-2000 problem," or Y2K, as many folks have taken to calling it. From many of the articles and news reports, you have probably deduced that this is a serious problem--one that could mean that thousands of computers across the world will not work properly, posing an enormous threat to businesses, governments, and the economy in general. Many people who have looked closely at the problem have become alarmists, predicting imminent doom between now and then. I know friends and associates who are making plans for food in case of a coming collapse of the power grid. I believe that most of the horror stories you're hearing will be averted, but we can avoid a real disaster only if we all do what we can to fix as many year-2000 problems as possible between now and then.

 

The most important thing you can do is make sure your business or organization is as prepared for the year 2000 as it can be. This problem is much more complex than it appears. I'll list concerns in order of priority.

 

The biggest burden is on critical infrastructure systems. I'm talking about systems that can't be down for even a day without a serious problem--whether we're talking about power systems, transportation, or other critical safety systems. In most cases, these rely on complex custom code for mainframes and/or lots of embedded systems in which it's hard to know all the dependencies. After all, you may have your firm's systems corrected but find that a critical supplier still has a problem. Work on identifying and correcting potential Y2K problems in such systems should have already begun. If you work with such a system, you should investigate now to make sure that the problem is under control.

 

The next concern is server-based applications, the kinds that are shared by multiple people and often end up running companies. Such systems range from off-the-shelf accounting, order-fulfillment, and messaging applications to custom applications designed specifically for your business. These applications cannot be fixed overnight, so you need to make sure your organization is taking steps to fix the problems as soon as possible.

 

Finally, we come to desktop machines. For yourself or for a small organization, taking the first few steps is not difficult. You can easily check whether the BIOS on an individual machine can handle the year 2000. Many vendors offer little utilities that check for the problem, and we've posted one on our Web site at www.pcmag.com/y2k. If your machine is new you probably don't have a problem, but it's better to be safe than sorry. We have heard some reports of relatively recent PCs with noncompliant BIOSes. If your PC's BIOS is not compliant, see our Web site for some fixes.

 

Similarly, checking your applications isn't hard. Most major vendors already have posted lists of which applications have Y2K problems and which don't. (To make it easier, we've collected these links as well as links to other Y2K resources at our site.) The challenge is much harder if you're running custom software. Then you must check your own code (if you wrote it) or get the vendor to warrant the software. In particular, you should check databases, spreadsheets, and various macros that use date math, especially if they pull data in from other systems.

 

This only becomes more difficult in a large organization, because it has to figure out how to roll out the correct changes to BIOSes, applications, and communications software to lots of machines. That's the kind of scenario that gives nightmares to IT professionals. Again, I think the worst of the problems can and will be averted, but not everything will be fixed in time. I particularly worry about embedded systems, enormously complex government systems, and systems in countries without much technology infrastructure. I'm much more optimistic about the machines most of us use in business--but only if we all work together to solve the Y2K problem.