In-Depth

PC BIOS Chips and the Year 2000

• 11/01/1998

Just about everything surrounding the Year 2000 crisis has taken on mythical proportions, accompanied by a glut of incomplete or unreliable information. Nowhere is that misinformation more damaging than in the PC BIOS (basic input/output systems) arena.

The publicity may border on sensationalism, but the basic concern is not to be taken lightly: When the year 2000 arrives, faulty BIOS chips will no doubt result in wrong dates read by applications, bad business data, PC crashes, and ultimately financial losses. To be effective in dealing with non-compliant BIOSes, IT managers need dependable answers to such questions as:

• What is the safe way to do a BIOS test?
• Do I have to perform an individual test on each desktop?
• What is the best way to fix a BIOS problem?
• Can I assume the BIOS in a new PC is Year-2000 compliant?

These and other questions will be addressed in this technology update, with particular emphasis on analyzing and fixing non-compliant PC BIOSes. PC BIOS: an accident looking for a century? Although conflicting opinions abound on solving the BIOS problem, there is consensus about the root of the problem. The issue has come under scrutiny because a PC’s software consults the BIOS to determine the time and date.

The BIOS in turn queries the real-time clock, which is located on the motherboard and has a small piece of battery-backed memory. This memory is commonly referred to as CMOS (Complementary Metal-Oxide Semiconductor).

The BIOS retrieves the month, day and year from the real-time clock, combines it with the century and returns the information to the software. Because the real-time clock keeps track of the time and date only in two-digit values, it is the BIOS that is in charge of changing the century. To do this, the BIOS writes to a place in the real-time clock memory where the century is stored.

In addition, the operating system sets its time at startup by accessing the real-time clock, through the BIOS. This is significant because the vast majority of applications get their date from the operating system. If the BIOS chip is not Year 2000-compliant, therefore, it will give the wrong information to the most basic daily tools that let us work and carry out business.

Due IT diligence in Year 2000 preparedness means that your desktops cannot be considered ready unless you’ve checked all PC BIOSes. Even new PCs should be tested, because some manufacturers put recycled BIOS chips in them. Other PC manufacturers alter BIOS chips when they install them. And you can’t assume that one machine of a certain make and model has the same BIOS as other machines of the same make and model, because that’s not always true.

To perform a thorough BIOS test, you need to get answers to the following three questions:

1. Will a PC continue to display the correct date after it’s rebooted? In some cases, a BIOS chip can roll over to the year 2000 if the computer is left on — but when you reboot the computer and the BIOS has to read the date from the real-time clock, it won’t accept a date beyond 1999.

2. Does the BIOS recognize 2000 as a leap year? This issue arises because the rule for calculating leap years is more complex than most people realize. Programmers with only a cursory knowledge of the full formula for leap year criteria could have incorrectly calculated that 2000 is not a leap year. Thus, some BIOSes will not be able to recognize Feb. 29, 2000, or any month thereafter.

3. Can the BIOS flawlessly roll over from 1999 to the year 2000?

Testing can be done either manually or automatically. In a manual test, the system date and time are changed by the user — a procedure recommended only for individual users or in very small computing environments. In an automated test, an IT manager runs a testing program tool that accesses the date and time at the hardware level, so the operating system clock is not disturbed. The pros and cons of manual and automated testing are discussed below.

Some IT managers have decided to address the issue by performing a manual reboot test of their BIOSes. You may want to review the commonly used procedures outlined below to see if you have used any of them. If you have, don’t be surprised if your results are not valid. And be sure to read the accompanying cautionary notes, because manual testing can be dangerous to the health of your enterprise:

• At bootup, press F1 (or the equivalent) to stop the bootup process and enter the CMOS utility, then reset the system date and time to Jan. 1, 2000, or Feb. 29, 2000.

• From DOS, use the DOS Date and Time command to reset the system date and time to Jan. 1, 2000, or Feb. 29, 2000.

• From Windows 3.1 and 3.11, use Program manager | Control Panel | Date/Time to reset the system date and time to Jan. 1, 2000, or Feb. 29, 2000.

• From Windows 95, use Start | Settings | Control Panel | Date/Time, or right-click the time in the Windows 95 task bar and choose Adjust Date/Time to reset the system date and time to Jan. 1, 2000, or Feb. 29, 2000.

Once you’ve set the clock ahead to Jan. 1, 2000, or Feb. 29, 2000, you can’t necessarily assume that the correct date and time will register after rebooting. Manually resetting the system date and time can give you inaccurate results about the BIOS, depending on your operating system and the procedure you use. For example, DOS is not Year 2000-compliant, and won’t show the correct date after rebooting. NT, on the other hand, will always show the correct date, for reasons explained in "Why NT Makes BIOS Testing Difficult," below.

Setting the Date Past Year 2000. If a user sets the system date and time past year 2000 or to leap year in any of the above ways to test the BIOS clock, the new settings may be accepted by the system BIOS and all software may continue to work as expected, even after rebooting. Don’t be misled by these tests, however, because they don’t test the ability of the BIOS clock to automatically roll over to the year 2000 or leap year.

Manually setting the date past year 2000 may be appropriate for individual users who aren’t concerned about the ability of their BIOS clocks to handle the actual rollover. When the time comes, they can manually set their system dates past year 2000 or to leap year and proceed as usual. It can also be an adequate procedure for a small group of PCs in a remote office, for example. But these tests are not practical for enterprises with large numbers of users, unless IT resources are unlimited; imagine the staff time needed to manually change 500 or more BIOSes to Jan. 1, 2000, and then again to Feb. 29, 2000.

Setting the Date Before Year 2000. Using the above methods to set the system date and time to just before year 2000 or leap year will test the rollover ability, but it is also fraught with uncertainty. You could theoretically set up the test, save your settings, and turn off the machine. Then wait the appropriate amount of time until the system clock has rolled over to year 2000 or the leap year. The drawback of this procedure is that IT managers won’t know — until it’s too late — whether the test causes corrupted files and data or expired passwords, schedules, and software licenses.

Running Tests with Applications Open. Don’t run any manual BIOS test while other applications are open. Some types of tests can corrupt software that is running. Other tests are too obtrusive from a user standpoint.

For IT managers in charge of large enterprises, certain automated testing tools can be the safest way to check PC BIOSes for Year 2000 compliance, because they don’t disturb the operating system clock. They are also more effective, requiring minimal user or IT interaction with the BIOS test and allowing the collected data to be compiled in a centralized reporting module.

A distinct advantage of automated testing is that it takes a fraction of the time required for manual tests. Giga Information Group did a recent analysis of manual and automated Year 2000 testing and repair. The analysis included software and hardware testing:

Using automated tools and a well planned strategy, enterprises should anticipate that each PC will require at least two hours to: (1) test for hardware Year 2000 compliance, (2) inventory installed applications and (3) repair as necessary and possible. Attempting to manually perform the testing and data gathering processes will easily double or triple this time estimate while overall testing effectiveness will be rapidly eroded.

Good network testing products will include centralized administration with automated testing across the network. Some BIOS tests can even be set up to run from a login script. Other desirable features include quick execution and centralized reporting of BIOS test results.

Windows NT presents a particular testing challenge, because the operating system architecture prevents programs from communicating directly with the BIOS. For NT 3.51 Service Pack 5 or NT 4.0 workstations, the NT operating system intercepts calls to the BIOS and "fixes" the date internally through Dec. 31, 2000. To date, there is no tool that can get past NT to test the BIOS.

The good news is that NT PC applications will receive correct time and date information. The bad news is that you can’t assume a given NT PC is Year 2000-compliant based on NT’s correction. This is especially crucial if operating systems other than NT are ever run on that PC. You might want to consider booting with a DOS floppy disk to test in this environment. (In addition, NT 3.51 Service Pack 5 and NT 4.0 fix the date only until Dec. 31, 2000, but not into 2001, so until that issue is addressed by Microsoft, IT managers need to be aware of another potential crisis waiting in the wings.)

Be skeptical of vendors who claim their products have successfully tested hardware in the NT environment and found no problems; they are either intentionally deceitful or unaware of this NT quirk, taking the favorable BIOS reports at face value. Wherever possible, go directly to the BIOS manufacturer for definitive evidence of Year 2000 compliance. Some Year 2000 software gets the BIOS information and cross references it with a database of vendor compliance statements for each BIOS version and date, so you can learn the compliance of the underlying BIOS despite NT.

Some users have dual or multiple bootable configurations, with one of the partitions running NT 4.0 and another partition running DOS, Windows 3.x, or Windows 95. To properly test in this environment, the BIOS testing should be run from a non-NT partition, or by using a bootable DOS floppy disk to do the testing at each machine.

Once you’ve determined which PC BIOS chips are out of compliance, you will need to remedy the situation. The solutions explored below range from conservative to extreme and differ considerably in their effectiveness.

Reset the System Clock. Beginning with the simplest fix, you can manually set your system clock after booting up on Jan. 1, 2000. As with the manual reboot test, however, this solution is appropriate only for very small shops or individual users because of time constraints and possible complications.

Do a Flash Upgrade. Some BIOSes are stored in flash memory rather than in permanent memory. These typically allow a limited number of upgrades that are done with software procedures. You must identify the specific motherboard manufacturer in order to apply the right patch. Most BIOS manufacturers have the flash upgrade files available for free, either on their Web site or on disk.

A flash upgrade can usually be done in less than a half-hour per machine. If you decide to rewrite the BIOS memory in this way, carefully follow the manufacturer’s instructions and then re-perform the rollover test on several machines to ensure it was successful, before applying the fix universally.

Replace the BIOS or Motherboard. If you have a hard-coded ROM BIOS, you will have to replace the chip with a newer one from the same vendor. Sometimes you can replace the BIOS chip only, but if the chip is embedded, you will need to replace the motherboard. While it might take 15 minutes per machine to replace a BIOS chip, it will probably take two hours or more per machine to replace a motherboard.

If no BIOS upgrade is available and you don’t want to tackle replacing the motherboard, you might want to pursue a solution that falls somewhere in between the two. A recent phenomenon is the appearance of "add-on" real-time clock cards on the market. Although there are still many unknowns in this realm, it could be a solution worth investigating, provided you proceed cautiously and do the requisite testing.

Replace PCs. This might be a good time to assess the relative value of the PC itself. If it’s an older PC that will soon need upgrading, consider that option. But remember: Whether you replace the BIOS chip, the motherboard, or the entire PC, you cannot presume Year 2000 compliance. Insist on a letter of compliance from the manufacturer. And even then, be sure to perform the rollover test.

Let the Network Server Provide the Time and Date. You can also configure your PCs to get the time and date from a network server, as long as your PCs are always connected to the server. If any of your PCs run independently of the network, this would not be an appropriate solution. Examples of this scenario might be users with laptops or other on-the-road devices, users who connect through Web links instead of logging in through the network server, and users who boot PCs independent of the network if the server goes down.

Implement TSR programs. Some remediation products provide a TSR (terminate and stay resident) fix for BIOS Year 2000 problems. The TSR sits between the BIOS read/write CMOS interrupt and the real-time clock. BIOS accuracy is so critical, however, most IT managers will be wary of relegating it to a TSR program, which may not be entirely reliable.

Two dangers exist with this approach. First, the TSR can be unintentionally corrupted or deleted by users. Second, not all applications refer to the BIOS interrupt for date and time information. The burden of maintaining the TSR and the business risk for failure of the installed systems weigh heavily against this proposed solution. In addition, there is no universal TSR fix.

Before undertaking risky workarounds or expensive overhauls of your network, carefully consider the Year 2000 compliance programs on the market. And don’t automatically accept PC manufacturers’ statements regarding compliance. Often, in their haste to apply the sticker that trumpets Year 2000

compliance, the BIOS issue is overlooked or overstated. In addition, a manufacturer’s pristine testing environment might produce results that don’t quite translate into real-world use. So even with a network of new PCs, perform automated compliance tests to verify that the BIOS has not been altered (or broken) by the PC manufacturer.

Performing automated network-wide testing for compliance is also the best course of action for established enterprises. Then scrupulously follow the manufacturer’s recommendations specific to each BIOS you find in your system. And most important, save time and money by doing it now, instead of waiting until it’s too late.

ABOUT THE AUTHOR:

To Sidebar