Ghost in the Machine

Roger Rebetsky

It is coming at a deliberate, predictable, unstoppable speed: 60 minutes per hour. Less than 410 working days from the time you read this article, it will land. It will cost $600 billion to fix - before the cost of lost business, lost productivity and litigation. It's the Millennium Bug, also known as the "Year 2000 Bug" or "Y2K Bug" for short.

Surely by now you have seen the ads warning you about the havoc the Y2K Bug can wreak. But do you really need to worry? Will it affect your business or cost you money? Possibly.

It's unlikely that your system is safe. If it isn't, your vital business records billing, dispatch schedules, payroll and anything processed on your computer are vulnerable.

Some would have you believe that Y2K is overrated and can be fixed easily. But think for a minute. What if all your receivable data is suddenly inaccessible? You wouldn't know who owes you what or when. How much business would you lose if your dispatch records are corrupted? These grim prospects are reason enough for you to spend time investigating the likelihood of a problem and how to solve it.

Refuse Systems are at a Greater Risk Here's a quick summary of the Y2K problem: Back in the old days (the '80s and early '90s) when RAM and disks were expensive, programmers routinely abbreviated the year to two digits to save valuable memory and disk space. So, when the year 2000 rolls around, most computers and software are going to think it's 1900, not 2000.

No big deal, right? Just change the date format to four digits, you think, and your problem is solved. However, if you think that's the quick-fix solution, you're forgetting that date references occur hundreds or thousands of times throughout your software and hardware. And each company, even each programmer, had its own way of writing software code.

The problem is especially severe in small, vertical industries such as refuse. Microsoft didn't write software for refuse haulers; small companies created refuse-specific systems. And while many of these programs have performed their functions extremely well in past years, little effort was ever made to make them conform to industry standards.

Remember Betamax video recorders? That's what your system is like. While the rest of the world was adopting "VHS" en masse, the refuse industry, and other vertical industries, continued to plod away blissfully with "Beta," which has not necessarily been a problem - until now.

Software's Achilles Heel The Y2K problem can't be explained fully without a simple overview. Three factors affect your system's ability to do the work you ask:

* Data is the information you put into the system.

* Data design is the way the data is recognized (i.e., the year is two digits, a name is all letters and no numbers, etc.).

* Program control is how the system recognizes, gathers, manipulates and outputs data. (When you tell it to produce a bill, it produces a bill.)

A typical application, say your billing module, will have at least 100,000 lines of code.

How many times does the date show up in those 100,000 lines? What happens when it does? Does it affect other modules?

Consider this: Do you keep your paper clips on your desk? On the left or right side? Front or back? In a drawer? Which drawer? In a box, cup or dispenser?

Just as everyone keeps his paper clips in a place that suits him, programmers put data, commands and vital processes in places that best suited them. Who could figure it out now? Even the original programmers would be hard-pressed to find all the problems in their 100,000+ lines of code.

The good news is that a standard now exists that keeps data, data formats and software design separate, so that they can be manipulated and function on any system, and so that programmers can find problems and make changes easily.

This standard, Structured Query Language (SQL) is like VHS: It'll record or play on any VCR (assuming you can figure out how to program the VCR).

SQL works on newer Windows 95-based systems. This alone is a good reason to trade up to a new system, because anything that is still DOS-based faces the "8-bit" limitation and a host of other inherited problems.

You can upgrade a DOS system again and again, and it never will operate on the "VHS" standard.

The benefits of a system with SQL database design are many. New hardware can be replaced seamlessly at no other cost than that of the hardware. The Windows operating system platform can be replaced easily with the newer Windows 98.

Most importantly, database software can be replaced with minimal or no effort. In other words, your system will be ready for the new generation of technology.

Keep Your Software Vendor Honest O.K., now that you know the why's and wherefore's of the Y2K problem, what do you do?

If you haven't done so already, call your software vendor. Find out if it is certifying its software to be Y2K compliant, and if not, ask what it is going to do to fix it.

You may have to purchase an upgrade, but your vendor should be willing to guarantee, in writing, that its system will work without interruption from Y2K date problems. If you can't get such a guarantee, start shopping for a new system now.

Even if your vendor gives you assurances, you're best off verifying Y2K compliance on your own, as well. A number of shareware programs are available - some on the Internet - to test your hardware. Also, "Does Your Software Pass the Y2k Test?" (see above) will help you determine if your system is prepared for the Millennium's technological terror.

Use this checklist to determine if your software system is fully "Year 2000" (Y2K) compliant. However, remember that you still will have to perform a separate hardware check.

If you are unable to check all of the boxes below, there is a high probability you have a Y2K problem and should seek professional assistance immediately.

* Display of date/century is clear and unambiguous.

* Printing of date/century is clear and unambiguous.

* Input of date/century is clear and unambiguous.

* Storage of date/century is clear and unambiguous.

* System uses four-digit date field.

* If your system uses a two-digit date field, it uses century logic to correctly infer century.

* System recognizes dates in 20th century (1900s).

* System recognizes dates in 21st century (2000s).

* System recognizes dates across century (mixes 1900s and 2000s).

* System crosses 1999 to 2000 successfully.

* System recognizes February 29, 2000 as a valid date.

* System recognizes Julian date 00060 as February 29, 2000.

* System recognizes Julian date 00366 as December 31, 2000.

* Arithmetic operations recognize that the year 2000 has 366 days.

* Note: Before running any type of verification test on your system, make sure you backup all of your software and data files, and then check that the backup works.

If your software uses the system date for security, automatic aging (or similar functions) or is licensed by time with an expiration date, do not perform these tests without professional assistance.