Preventing Chaos

April 1, 1999
The Year-2000 (Y2K) problem is sure to produce varying results, confusion and concern for educational institutions. Many computer-based systems will be

The Year-2000 (Y2K) problem is sure to produce varying results, confusion and concern for educational institutions. Many computer-based systems will be adversely affected byY2K unless necessary actions and corrective measures are taken to test, upgrade or replace components, systems and software to eliminate the effects of the changeover to the new millennium. It is especially important to understand Y2K and its potential effects on crucial operations, such as fire-alarm and security systems.

The term "millennium bug" has been used to describe various negative effects on the operation of computers caused by the change into the 21st century. However, it is not a bug; it is a design flaw that was unintentionally created because of lack of foresight by the manufacturers, designers and programmers. It cannot be repaired because nothing is broken-computers are running precisely as designed.

The impact will be felt because some computers running these systems will not be able to recognize the year 2000. The year codes were programmed to be a two-digit field (yy), as opposed to four digits (yyyy). Because of the cost and limited memory space in the early days, the "19" often was omitted, thereby requiring just the two-digit code for the year. It was assumed that the BIOS (Basic Input/Output System) would keep track of the century. However, this may not be the case.

Life-safety and fire-protection systems may not work at the onset of the year 2000. Life and property may be in jeopardy during fire and smoke emergencies, which may lead to possible liability and legal implications. The same applies with security systems, but with definite legal ramifications. For instance, any events recorded on CCTV and access-control systems could not be used as evidence in legal proceedings; they would be deemed useless since the records would display incorrect dates.

A ticking time bomb Most computers contain two clocks:

-Built-in hardware clock (real-time clock or RTC). This clock runs whether the system is on or off.

-Virtual clock (system clock). This clock is set to the real-time clock when the computer is turned on and exists only while the computer is operating.

While the computer is up and running, the two clocks run independently of each other. However, the RTC can be set to any nonsensical value, and the operating system will not notice. This will occur January 1, 2000 if your system does not support the year 2000. As long as the system is running, the operating system will support the occurrence of the year 2000 correctly. Problems will occur, however, when the system is shut down and rebooted, or powered off then on.

The system clock is a 24-hour timer and has no concept of days, whereas the real-time clock tracks the time and date. In fact, the system clock has no concept of traditional hours, minutes and seconds. It merely increments a counter 18.2 times per second. The operating system, which is dependent upon the system clock for the time, converts the counter into hours, minutes and seconds. As for the date, the operating system reads the real-time clock via the BIOS during initialization, then tracks the date independently based on the virtual system clock rolling over midnight.

The RTC used in most computers does not track centuries-only years. After December 31, 1999, the RTC merely indicates the year 00. With the software encoded within, it is the BIOS' responsibility to track the century and preserve that information in the RTC's non-volatile memory. The BIOS assumes that the years 1900 through 1979 cannot occur, so when the year is within 00 to 79 and the current century information is 19, the BIOS sets the century information to 20. If the BIOS does not track the century, the operating system will be given an invalid year and most likely will assume either 1900 or 1980.

The most significant hardware problem with computers is not due to lack of storage space, but rather the inability of many, and usually older machines, to make the transition from 12/31/99 (December 31, 1999) to 1/1/2000 (January 1, 2000) automatically. The 2-digit year and the current century are stored separately in memory. Adding 1 to 99 results in 00, which is correct as long as the century is changed from19 to 20 at the same time. If the century is not updated, the current date held internally by the computer is 1/1/1900-even though the operating system may show 1/1/2000. When the computer is rebooted while the internal clock is in this state, part of the initialization and self-test routine decides that 1/1/1900 is not a valid date and resets the clock to its earliest known date-in many cases 1980.

Software concerns Non-compliant software will not function correctly because of shortcuts taken by programmers when designing and writing applications. In order to save memory, dates were stored in mm/dd/yy format. This causes a problem at the end of a century because the date rolls over from 12/31/99 to 1/1/00-which, as far as the computer is concerned, is almost 100 years earlier, or 1900. Thus, any calculations made using dates will be incorrect.

According to computer experts, the problem here is that any information that requires the computer to calculate the length of time will come up with the wrong amount of time. Time is an ever-increasing number in the computer world, which is limited to ones and tens with no concept of the hundreds column. Therefore, depending on how they were programmed, computers could give the following results:

-They will not receive or compute the data that is fed into them if the year is 00 or higher. The screen simply will wait for data that means something to the computer, or it will advise of an invalid date and will not compute.

-It will not be able to handle the end result (wrong data) and will shut down, freeze up and crash. According to experts, this is preferable to destroying the database with the wrong data computed. However, this is still a failure.

Testing and validation Comprehensive testing with a Y2K-compliant computer is necessary to ensure that software, especially time/date-sensitive programs, operates as required by its application.

When dealing with computer systems, such as the ones used on fire and security systems, testing may be necessary to determine if the PCs and software are compliant. This usually is performed by manipulating different test dates; shutting down and rebooting the system for automatic time/date progressions; testing individual components (head-end processor and field data gathering panels with RTCs that are host-dependent) on-line and off-line; and testing the entire system.

Testing and validation takes time and will consume most of the costs associated with fixing the Y2K problem. Preparations must be made in advance; information must be obtained from manufacturers, and testing procedures must be prepared.

Setting the time and date just prior to the year 2000 and just letting the new year occur is not a valid test. The RTC may be invalid, but the date according to the operating system will be correct. The system must be powered off then on to complete this type of test.

Perhaps the easiest way to test the PC is with the use of software programs from companies who specialize in this particular field. Some software can test the BIOS and RTC functionality for its ability to support the year 2000. However, operating systems and other applications should be tested separately.

System remediation Non-compliant fire and security systems (hardware and software) must be remediated to support Y2K and leap years. Remediation may include one or more of the following:

-Upgrade or replace non-compliant BIOS.

-Upgrade or replace non-compliant field DGPs, PCs or systems.

-Upgrade or replace non-compliant software.

Plan contingencies well in advance in anticipation for the worst. If the system goes down, place contingency plans in motion. Support personnel, such as security guards, may need to be posted in lobbies, entrances and exits in the event of a fire emergency or security breach. If the system can support year 1972, reboot the system using 1972 as the contingency year (1972 is the last year that replicates the year 2000).

The computer problem does not just deal with fire and security systems. Any system that uses date or date-dependent and date-sensitive data will be affected. It will take time to rebuild these critical systems; unfortunately, at this point, time is critical.

Some systems will continue to run and will continue to support Y2K, but only for as long as they are running. Problems will occur, however, when the system is shut down and rebooted, or powered off then on. Having a new or fairly new system does not guarantee the absence of Y2K-related problems. Testing and validation still must be performed to determine year-2000 support.

At the very minimum, the following critical dates should be tested for Y2K compliance:

-1972-This is the last year that replicates the year 2000, but may sometimes prove to be an invalid date on some systems. This also is the "contingency year" that can be used if everything else fails.

-September 9, 1999-Some programmers use this date (9/9/99) as an end date-an arbitrary selection done randomly, and if this is the case, your system will stop working on this date.

-December 31, 1999-For progression after midnight into January 1, 2000.

-January 1, 2000-Test the RTC, applications, date-sensitive and date-dependent data to make sure everything is intact and nothing has become corrupt.

-February 28, 2000-For progression after midnight into February 29, 2000 (for leap-year support) and RTC test.

-February 29, 2000-For progression after midnight into March 1, 2000, and RTC test.

-February 28, 2004-For progression after midnight into February 29, 2004 (for leap-year support), and RTC test.

-February 29, 2004-For progression after midnight into March 1, 2004, and RTC test.

It is important to understand how and why systems and computers may fail on January 1, 2000, if the problems are not corrected now:

-In most systems "19" (or its value) was hardcoded into the software routine for the implied century and provided only a two-digit entry for the year code (as in '99' or '00') as reserved values that basically omitted the century portion of the year. In the year 2000, these systems would compute the year as 1900, meaning the system does not recognize the year 2000. To complicate things, the year 2000 is a leap year.

-Other systems will recognize only a set number of years, such as 80 to 99. Any combination of numbers falling outside this range simply will not compute or be recognized by the computer, or will result in the computer automatically changing the offending number to a date that does compute.

-Some systems will not recognize any number higher than 99.

Sponsored Recommendations