By Ramona Taylor
"The Millenium Bug." That's what they call it in Australia. And they're just as worried about it as we are about our "Year 2000 Bug." Almost any software problem 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 program counted 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 just starting 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 him that Space Control software was not afflicted with this "pest." But I don't think 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 the first place.
In the early days of programming, unlike today, computer memory and storage were very scarce. Every programmer searched for ways to get the job done without using a whole lot of memory or disk space. So, when dealing with dates, Nov. 24, 1973, quickly became 112473. Dropping two digits may not seem like that much space savings, but if you think about all the dates in your tenant accounts, reports, rent raises, delinquent tenant accounts, etc., you'll see that it adds up. Then consider that 1980 computers had about 16,000 times less storage than today's computers and you begin to see the programmer's dilemma. 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 customers pays years in advance, to the year 2000, your software may show him as being 35,000 days late. The program compares 00 to 98 and comes up with a whole bunch past due. The number may actually show as something less than 35,000 because most programs have some limit on the size of any given calculation. This has already been reported in some storage software. (The thing I wonder about is, where do they get these customers who pay years in advance?) But, this is not a terrible bug. You certainly know your customer is not 35,000 days 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 that calculates 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 are still 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 printed material to see how the account is listed. Be sure to look at monthly reports as well as daily ones. Watch for "late" letters generated for this account. Of course, you will have to back this fake payment from your accounting information, since it is only being entered for testing purposes. (I feel like I should say something here about checking with your manager or bookkeeper before proceeding.)
When you have concluded this test, reverse the original payment that moved your account three 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 take our paid-to dates backward to a year of a smaller number. This reversal will have to go from the year '00 to a bigger number of '98. See if it goes back to the original paid-to date and balances correctly.
Other ways that the year '00 could cause trouble are more problematic. If your software requires 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 get into 2000. This is because most programmers (at least the good ones) try to prevent users from making obvious mistakes. For example, if you typed in November 32 instead of November 23, 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, the software 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 rent spaces that are paid to January 2000. And when you get to January 2000, you may not be able to have the current date shown on your screen, receipts, reports, etc. I guess a worst-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, you would have to copy your entire system onto another computer, somehow advance the date to 1999, then go through every process that the software covers. A complete test should cover the 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 cases it can be related to the computer thinking the year 2000 is the year 1900. I can't think of any way this could affect the number of spaces at your storage facility. Nor could it affect the amount of money collected on any given day. It could affect how much money is past-due or prepaid if your software is using paid-to dates to calculate balances. So, if your software did something that you think was wrong, look to see if a date of 2000 is involved. If not, it is not likely that you are experiencing "The Millennium Bug." 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 bigger problem in older main-frame computers than in the desk-top PC-type computers. Some of the programming 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, the program is still running along doing that same job. It may not have been changed, updated or even looked at in years. In some cases, the source code (which the programmer works with) may even be lost. That's the reason people are very concerned, as we approach the year 2000, about the computers in our big institutions like banking, insurance, etc. So this is only good news in that it makes storage software running on a PC somewhat less vulnerable to this bug. It does give us some idea of why we are starting to hear so much about the problem in general.
Ramona Taylor is president of Space Control Systems Inc., one of the world's largest suppliers of management software for the self-storage industry. For more information about Space Control products, call (510) 943-6222, (800) 455-9055, or e-mail [email protected].
