Y2K Ain't Scary, Really

I was hoping to avoid this subject, but several e-mails have prompted me to write a few columns on the year 2000 problem (affectionately known as Y2K). There has been more hype, predictions of disaster, and general overreaction to Y2K than any subject in the last few years (save perhaps the introduction of Windows 95). 

Let's start with a simple statement: the word will not end January 1, 2000. Computers will not self-destruct. Airplanes will not fall from the sky. Banks will not suddenly lose your money (at least not more than they do now). Cars will still start, work will still go on, and the word will look every bit the same as it did New Year's Eve (with the possible exception of bleary eyes and a hangover). You do not need to hire $5,000-a-day consultants to "fix" your systems. (Although, I am available at that rate if you do feel so inclined.) 

Why is the Y2K issue so sensitive and troublesome? Largely because of ignorance. I hope in the next few columns to help straighten out the issues that you, as VARs, will encounter, and provide solid information you and your customers can rely on. A quick background brief on the problem is a good way to start, for those of you who have been hibernating the last five years or so. 

In the good old days of programming (five years ago or so), developers had to try and keep memory usage to a minimum. When you only had 64k or less of RAM to work with, each byte in a large application counted. And we're not talking PCs only, here. The same applied to minicomputers and mainframes. To save bytes, programmers and applications such as databases would store data about a calendar year as two numbers: 69 for 1969, 75 for 1975, and so on. Since most of this software was not intended to be used for very long, the issue of the 19 preceding the year numbers changing to 20 didn't crop up in most of our minds. After all, we all expected our software to be rewritten and improved as the years went by.

The Y2K issue arises not because of the decade rolling over but because of the magical number 19 that precedes all our dates. When that becomes 20 (as in 2000), some software will miscalculate formulae. For example, suppose you are storing information about a person's age based on their birth date. If the entry is 60 (for 1960), the formula for calculating age works well in 1999. Take 99, subtract 60, and the person is 39 years old. But when the 2000 year rolls around and only the last two digits in the year are handled, the person suddenly become 00 minus 60, or -60 years old. Common sense tells us this type of calculation should be easy to fix, right? If the formula ends up with a negative number, simply add 100 to the years to get 40, the correct number. Unfortunately, common sense isn't something computers have built in. To tell them to add 100, we have to modify the program to add the new rule. 

So, anytime there is a date calculation we need to check to make sure the roll-over from 99 to 00 keeps the calculations legitimate and accurate. Why this isn't as easy as it should be is two-fold. First, many old applications written in languages like COBOL and FORTRAN are still in use throughout our industry. (Remember those we intended to rewrite before too long? Nobody did.) There are few programmers still around who know and understand these older languages, and even fewer yet who have the skills to wade through several hundred thousand lines of code looking for suspect date calculations. 

Second, many database programs we used to write applications in the sixties through eighties can't handle four-digit dates. They were written to allow two digits, and those database packages must be updated before the applications that use the databases can be corrected. Some of the older databases are not supported today, their vendors long since bought out, bankrupt, or retired. So, for companies using older databases (or similar applications like spreadsheets, programming toolkits, and statistics packages) the core of the system, the engine, must be rewritten first, then the application after that. 

All of this re-coding takes time, and since no-one bothered to get worried about these date calculations until two or three years ago, there's a massive panic to find programmers, money, and time.

Oh, there is a peripheral issue about the Y2K problem that some software can't handle. The year 2000 is a leap year. (For those into trivia, the rule established by Pope Gregory in September 1752, when the Gregorian calendar was adopted, is that every four years is a leap year with an extra day added in February, except when the year is divisible by 100. However, this isn't quite exact enough, so when the year is divisible by 400, it is a leap year. So, 1900 was not a leap year, 2000 is, 2100 isn't., and so on.) Since most applications automatically figure that century dates are not leap years, some software will be out by a day on March 1, 2000. That problem has to be corrected by re-coding, too, where applicable.

Finally, software isn't the only problem. Many hardware devices with dates programmed into them (including BIOS chips for computers) can't handle the roll over in the same way as software, either. These are much harder to fix as the offending devices have to be found and a new BIOS burned and implanted.

In the next few columns we'll see how to identify suspect software, test for the Y2K problem, and also fix some of the issues yourself. In the meantime, feel free to send $5,000 consulting fees to me in advance. Trust me, I'm worth it!