Getting started on Y2K 

Last column we started looking at the year 2000 problem. While some disagree with my assessment that the world is safe from disaster on January 1, 2000, that doesn't mean you don't have to do a little advance preparation to make sure your own corner of the world isn't bothered by the Y2K bug. 

We've already identified the three main sources of problems: software that can't handle date calculations after the roll-over, leap year problems, and hardware limitations in the way 200 roll-overs are performed. The latter is often treated as a minor issue by VARs, since most PCs sold in the last five years or so have BIOS chips capable of passing 2000 without problem, but remember two things: there are a lot of old PCs out there, and PCs are not the only devices we need to look at! What about your telephone system? How about your fax machine? Will your network hub or switch stop hubbing or switching? Will your motion sensors in your alarm system work properly after 2000? Your security access system may lock you out! There are many hardware devices we take for granted that we don't even think of as computers, but many have embedded controllers that are not capable of handling the century passage.

What about legal problems? Can a customer sue you for not delivering hardware, software, or supplied because of a roll-over glitch in your ordering system? Can you sue suppliers who have the same problems? If you supplied software to a customer that is not Y2K compliant, can you be held responsible? Don't ask me, I'm not a lawyer. However, from what I've been told the answers are yes, yes, and yes. In fact, the lawsuits have already started in the US, on one case involving software written decades ago! 

How do you take care of these problems? Start by carefully considering the issues involved, and don't forget a few basic rules about the Y2K problem. (These may seem self-evident, but you'd be surprised how many vendors I've talked to that are not taking this issue seriously yet.) The most important rule is this: the deadline won't slip! January 1, 2000 comes precisely on that date. We can't postpone it to add new features, because the advertising isn't ready, or to get fancier packaging. There are only eleven months left before this deadline, and that's not a lot of time.

Second important rule: don't delay. If you think you can wait until November then call a consultant to fix your problems, you're going to be disappointed. Every consultant who knows what they are doing (and many who don't) are already working to their capacity on this issue. By the latter half of this year, they will be working long days and will have not time to help out yet another client. Get started now, of you haven't already!

The third rule is a corollary of the second: there are only a limited number of people who can help you out properly, so get them lined up immediately. Calling "Joes's Laundry and Y2K Fixers" in November isn't going to help you much. There are very few true experts in the Y2K field, and they are all working hard (and at pretty good daily rates). As time passes, they get busier and more expensive. Got COBOL course code to patch? How many COBOL programmers do you think there are who can wade through millions of lines of code in a few months? The same applies to FORTRAN, Basic, FoxBase, and every other language used in applications.

Fourth rule, also a follow-on from the second and third: don't think you can throw more money and people at the problem and get it done faster. Often, two programmers working on the same issue will take longer than one who knows what they are doing. Adding dozens of programmers to a task doesn't speed up the solution; it merely adds to the problems.

Get started now with identification of the problems themselves. You don't have to fix the problems, but knowing how big they are and getting some idea of the overall scope of the fixes lets you know if the problems can be fixed, how much time it will take, and how much money you have to spend. 

So, you think all of this doesn't apply to the average VAR? You may be one of the lucky ones who won't be affected, but if you have been involved in installing custom software, modifying applications, installing networks, setting up gateways and firewalls, or any other task involving date-sensitive hardware or software, guess who the client is going to call? Solve your in-house problems first, then take care of the clients. Begin by looking at all the software you use in the daily passage of business. Is your accounting, invoicing and inventory software going to work properly past 2000? You need this stuff to stay in business. Will your internal network still function? How about any automated telephone system? In future columns I'll show you how to check all this stuff, and what you can do to fix it if possible. 

After you've taken care of the in-house stuff, call your customers! They will appreciate the attention and the follow-up, even if you know they are safe from the dreaded wrap-around issue. In some cases you may have to recommend fixes or upgrades, and those need to be discussed with the clients carefully, as some will resent having to spend more money to fix something they already paid for. (No one said a VAR's life was easy!).

Next column, we start looking at the ways you can fix problems for Y2K, one by one.