How does your software feel about......the year 2000?

By Ramona Taylor

"The Millenium Bug." That's what they call it in Australia. And they're justas worried about it as we are about our "Year 2000 Bug." Almost any softwareproblem that pops up these days is likely to be blamed on this highly publicized glitch.For example, at a recent industry trade show a man told me that his software programcounted the number of spaces at his facility incorrectly in August. Then, in September,some of his reports were unable to print. So, he concluded that this was the 2000 Bug juststarting to manifest itself, and that it would continue to get worse until January 1,2000. He was shopping for new software. His only question to software vendors was,"Does your software have the 2000 bug?" Fortunately, I was able to assure himthat Space Control software was not afflicted with this "pest." But I don'tthink I completely convinced him that the 2000 Bug was not his problem.

The 2000 Bug is a very specific problem and will only manifest itself in certain ways.To better understand what to look for, let's look at how this thing came about in thefirst place.

In the early days of programming, unlike today, computer memory and storage were veryscarce. Every programmer searched for ways to get the job done without using a whole lotof memory or disk space. So, when dealing with dates, Nov. 24, 1973, quickly became112473. Dropping two digits may not seem like that much space savings, but if you thinkabout all the dates in your tenant accounts, reports, rent raises, delinquent tenantaccounts, etc., you'll see that it adds up. Then consider that 1980 computers had about16,000 times less storage than today's computers and you begin to see the programmer'sdilemma. Consequently, the first two digits of the year got dropped completely.

That explains one way this bug could affect storage software. If one of your customerspays years in advance, to the year 2000, your software may show him as being 35,000 dayslate. The program compares 00 to 98 and comes up with a whole bunch past due. The numbermay actually show as something less than 35,000 because most programs have some limit onthe size of any given calculation. This has already been reported in some storagesoftware. (The thing I wonder about is, where do they get these customers who pay years inadvance?) But, this is not a terrible bug. You certainly know your customer is not 35,000days late. And you know this wonderful person should not be on your past-due report. But,keep an eye out for late notices and invoices. You don't want to mail out something thatcalculates a huge balance-due based on a supposed paid-to date of 1900.

If you haven't been fortunate enough to have a renter pay years in advance, there arestill ways to test for this particular bug. It requires some work, but it may be worth it.You need an account that is not a "real" customer--perhaps one in your own name,some member of your family, or a close friend. Pay that account up into the year 2000,leave it that way for a month or so and see what happens. Check all screens and printedmaterial to see how the account is listed. Be sure to look at monthly reports as well asdaily ones. Watch for "late" letters generated for this account. Of course, youwill have to back this fake payment from your accounting information, since it is onlybeing entered for testing purposes. (I feel like I should say something here aboutchecking with your manager or bookkeeper before proceeding.)

When you have concluded this test, reverse the original payment that moved your accountthree years ahead. Not only does this get your test account back to its correct balance,but it allows you to check out another possible problem. Payment reversals typically takeour paid-to dates backward to a year of a smaller number. This reversal will have to gofrom the year '00 to a bigger number of '98. See if it goes back to the original paid-todate and balances correctly.

Other ways that the year '00 could cause trouble are more problematic. If your softwarerequires you to type in the date, whether it is today's date, a customer's move-in date,or whatever, it is possible that the system will not accept your typed-in date when we getinto 2000. This is because most programmers (at least the good ones) try to prevent usersfrom making obvious mistakes. For example, if you typed in November 32 instead of November23, you would expect your software to beep and complain about that not being a valid date.The trouble is, depending on how the original programmer wrote the date checks, thesoftware may beep and complain the same way about the year being '00.

This is a bigger problem because it may mean that in December 1999, you can't rentspaces that are paid to January 2000. And when you get to January 2000, you may not beable to have the current date shown on your screen, receipts, reports, etc. I guess aworst-case scenario would be not being able to enter rented spaces into the computer. And,this is much harder to test for than the prepaid customer situation. To test this, youwould have to copy your entire system onto another computer, somehow advance the date to1999, then go through every process that the software covers. A complete test should coverthe last months of 1999 and the first months of 2000.

The thing to notice here is that the 2000 bug only has to do with dates. In most casesit can be related to the computer thinking the year 2000 is the year 1900. I can't thinkof any way this could affect the number of spaces at your storage facility. Nor could itaffect the amount of money collected on any given day. It could affect how much money ispast-due or prepaid if your software is using paid-to dates to calculate balances. So, ifyour software did something that you think was wrong, look to see if a date of 2000 isinvolved. If not, it is not likely that you are experiencing "The MillenniumBug." It may not be a bug at all, but a glitch like we all encounter now and then.

Now, for the good news. In general, this 2000 Bug is expected to be a much biggerproblem in older main-frame computers than in the desk-top PC-type computers. Some of theprogramming code for those big main-frames was written a lot longer ago than any PC code.Some of it was written to do a particular job and, because the job hasn't changed, theprogram is still running along doing that same job. It may not have been changed, updatedor even looked at in years. In some cases, the source code (which the programmer workswith) may even be lost. That's the reason people are very concerned, as we approach theyear 2000, about the computers in our big institutions like banking, insurance, etc. Sothis is only good news in that it makes storage software running on a PC somewhat lessvulnerable to this bug. It does give us some idea of why we are starting to hear so muchabout the problem in general.

Ramona Taylor is president of Space Control Systems Inc., one of theworld's largest suppliers of management software for the self-storage industry. For moreinformation about Space Control products, call (510) 943-6222, (800) 455-9055, or e-mail [email protected].