SEAV Softwares: The Millennium Bug and the QBASIC Delay Subroutine

The Millennium Bug and the QBASIC Delay Subroutine

By SEAV

Imagine yourself, celebrating the new millennium. You count down the last few seconds till January 1, 2000. You feel excitement all around you. Five...four...three...two...one.... Immediately, the power goes out. You suddenly think that Armageddon had come. Human civilization is finished! But nothing untoward happens. You're alive—probably tipsy from all the wine you drank.

Yet as you examine the world all around you, you realize that many things seem to be wrong. Your ATM card is suddenly not working. Elevators are stuck on the ground floor and would not move. Your cellular phones become useless. Many things all around you cease to function, work erroneously, or simply crash.

Such may be the peril faced by people due to the insidious Millennium Bug, also known as the Year 2000 Problem or Y2K.

The Millennium Bug

What the heck is the Millennium Bug? Surely you (whom I assume to be a programmer) know that. But, anyway, here's the meaning. The Millennium Bug is probably the worst problem people using and depending on computers face. The problem lies in the way almost all computers handle dates—by dropping off the first two digits of the year. Thus, January 15, 1998 becomes 01-15-98. Obviously, such treatment of years would have problems when you're dealing with centuries.

This way of handling dates dates back to the time when computers were expensive and every byte of memory, a precious commodity. Programmers who hard-wired the code in early computers dropped off the two digits to save space. Unfortunately, this has become the standard and has since then been used on almost all computer systems.

The Millennium Bug is one of the best examples of shortsightedness there is. (Another example was when the computer dinosaurs of old said that nobody would ever really need more than a megabyte of memory. Consequently, they designed PC processors to have access to only one meg of memory.)

Is the Millennium Bug really that serious? Yes. Hundreds of thousands of mainframe computers around the world make calculations on dates. Imagine for example your ATM card. Suppose it has an expiration date of March 5, 2002. If the year was recorded as 98 and you used the card on December 4, 1999 (for Christmas shopping), some computerized card reader might erroneously think the card is expired since it would read only the 02 part of the expiration date and 99 is greater than 02!

Now adapt the situation to computerized telephone and cellular systems, automated medical databases, insurance systems, motor vehicle registration, military weapons procurement, nuclear power plant maintenance, banking systems, the stock market, etc. You'll see the enormous extent of the problem.

Analysts say that it would take around $300 to $600 billion to solve the problem, not to mention the litigation costs that might reach $1 trillion against companies whose systems would fail. Incidentally, we only have less than two years to solve the problem.

Isn't it easy to solve the problem? Well, no. In most mainframe computer programs, the date appears about once every 50 lines of code. It's very hard to find these lines, harder to change those lines, and even harder to test and debug the changed programs. Plus, consider the compatibility problems these computers face especially when they are connected with each other via networks such as the Internet.

The QBASIC Delay Subroutine

Let's us show why the Millennium Bug is so important by examining an analogy in QBASIC. Let's suppose that you are programming some piece of software and that you need to have a handy Delay subroutine. You decide that you'll use the TIMER function to time the delay. You then code in the following lines (or a variation of them).

SUB Delay (Secs!) FTime! = TIMER + Secs! DO LOOP UNTIL TIMER >= FTime! END SUB

Okay, it works fine, and it suits your purposes well. But, if you're insightful enough, you'd wonder what happens when FTime! jumps the midnight value? What will happen if FTime! is calculated to a value greater than 86,400? Obviously, the program would go through an infinite loop since TIMER can only give values below 86,400.

You might think that this code is enough because you reason that the chances of somebody using the program at midnight is slim. But if you're the responsible programmer, you'd eliminate this problem:

SUB Delay (Secs!) FTime! = TIMER + Secs! IF FTime! > 86400 THEN FTime! = FTime! - 86400 END IF DO LOOP UNTIL TIMER >= FTime! END SUB

This piece of code would solve the problem of the infinite loop alright, but will definitely cut short your delays at midnight because, then, the value of FTime! would be smaller than TIMER, immediately. This is better than an infinite loop, but if you feel that you really need those 5-second delays, you change the code a bit.

SUB Delay (Secs!) FTime! = TIMER + Secs! IF FTime! > 86400 THEN FTime! = FTime! - 86400 END IF DO LOOP UNTIL TIMER >= FTime! AND _ (TIMER - FTime!) < 1 END SUB

The change in the code makes sure that the difference between the TIMER and the FTime! values would be less than one, thus preserving the delay period.

What the QBASIC programmer needs to solve is the problem in time computations when the TIMER cycle is jumped at midnight. Additional problems include those projects where you need to time parts of your program. Complications occur when users inadvertently or intentionally change the time during the delay or the timing, thus throwing the program out of sync.

This simple problem in QBASIC reflects the problems faced by the people with the Year 2000 Problem—2000 times 2000 times worse. Imagine what would happen to computer systems around the world when the new millennium sets in. There are millions of computer systems that use date-sensitive calculations and these systems would definitely give the wrong results or even worse, crash.

Reference:
Levy, S. and Hafner, K. "The Day the World Shuts Down."

Newsweek Magazine. June 2, 1997.