Although you can set the system date on most PCs to 2000 (or 00), when you reboot, the CMOS date might assume that 00 means 1900 and override the RTC date. Because 1900 is an invalid year (there weren't any computers in 1900), both DOS and Windows assume 00 means their day one. To DOS, day one is January 4, 1980, and DOS will set CMOS to that date. The BIOS will think 00 means 1900, until it receives a command from the operating system (OS) synchronizing it with the CMOS date. Then the system will be in sync--but on the wrong date. NT won't be as confused by date synchronization (it's likely to come up with the correct software century), but it can't correct invalid or missing hardware and firmware century digits.
If you cycle the PC's system date to 2000, the system date and its CMOS date might be 100 years apart. If you power on the system during the rollover to January 1, 2000, the same discrepancy between system date and CMOS date can occur. The CMOS and BIOS dates won't set properly until you give the OS a command, such as a minor modification in the time.
I don't know of specific tests to check network hubs, gateways, and routers for Y2K problems, but you can contact manufacturers and scan the Internet to locate such tests. Equipment manufacturers can tell you where problems may occur in their hardware, but don't take a vendor's word that its network equipment is Y2K-compliant--conduct tests on your equipment to be certain. Look for hidden elements on your network hardware that might pose problems in the same way CMOS and BIOS dates compromise PCs. The nature of these hidden elements might vary on different types of hardware, but the basic problem is the same: Software isn't the only thing that can hang you out to dry on January 1, 2000.
Checking software. COBOL is not the only legacy language with 2-digit year fields--it just receives the most press because so much COBOL code is out there. Other languages with 2-digit year fields include PL/1, assembly language, Easytrieve, and various levels of CICS, not to mention the many antiquated--and unsupported--languages still running in legacy systems. The GartnerGroup and other research firms have compiled statistics based on language and number of lines of code that can help you form estimates of how long it will take to find a particular language's date routines and modify the code (http://www.gartner.com). However, finding all the date routines can be a challenge. Some date routines are properly labeled (e.g., Calculate Expiration Date), but others aren't (e.g., Ralph's Routine). The hardest date routines to find are those that aren't labeled. Some date routines use Year, Month, and Day fields, whereas others might use, for example, Workarea+30. Some systems might even calculate the date based on minutes or seconds from system initiation time.
To check thoroughly for Y2K software compliance, you need to go through the source-code listings of all your legacy code line by line to find lines that reference, use, or calculate dates; then you must determine what the code does with those dates. Software packages exist that can help you identify how much of a problem you have and where the offending lines of code are.
Be aware that the 2-digit year field is not solely a legacy system problem. Many vendors have translated programs into 4GLsinstead of redesigning and programming from scratch--to save time and money. Thus, date problems in the translated programs have propagated to new generations of programs, some of them current off-the-shelf software. For example, Windows 95 interprets dates between 1980 and 2099 correctly, whereas some Windows 3.1 applications interpret dates from 2000 through 2020 as 1900 through 1920. Because Windows 3.1 is an old OS, I don't expect vendors to fix Y2K problems with Windows 3.1 applications. However, because programs such as Excel (which in version 5.0 can handle cell dates only through 2019, reverting to 1920 the following year) are current products, I expect vendors to correct problems in all such products and their applications. Be aware of the likelihood that, to correct Y2K problems in its products, a vendor might require that you purchase product upgrades. Even if you receive a free upgrade, you must spend the time necessary to install it. And you'll need to retest all an application's interactions after you install the upgrade.
OSs. Although NT has relatively few Y2K problems, version 5.0 might not be completely Y2K-compliant. However, you can expect Microsoft to hustle to make NT compliant. (Not only will Microsoft want to avoid legal hassles, the company will have internal computer problems on January 1, 2000, if NT 5.0 isn't Y2K-compliant.) But even if you assume that NT will be Y2K-compliant by the time the century turns (for example, NT 4.0 SP4 includes Y2K hotfixes), you still must allow time to install and test Y2K fixes against your code.
Reliable sources report that NT uses a technique called date windowing in some places in the OS to accomplish Y2K compliance. This technique moves the window of date validity from, for example, 1900 through 1999 to 1941 through 2040, postponing the necessity of changing year fields to 4 digits. When a program uses windowing, any other programs the windowed program interfaces with must either implement windowing or provide a bridge program to windowed systems. Bridge programs are becoming increasingly popular as a means of disarming the Y2K time bomb. However, date windowing and bridges merely delay the crisis--they don't solve the problem.
Embedded systems. Our society now includes microprocessors in many different items. We have smart cars, automated security systems, robotic manufacturing plants, and computerized medical devices. I guarantee that all such microprocessors won't fail on January 1, 2000. But suppose we take a conservative view and assume that just 1 percent of these embedded microprocessors fail. Which ones will they be? I won't paint a nightmare scenario and talk about airplanes falling from the skies and pacemakers stopping, but there are other, less disastrous possibilities. Will the baggage-handling system at the airport fail? Will traffic lights stop working? What about your office's furnace controls and air conditioning? The point I want to make is that no one knows which embedded systems will fail at the century mark and which won't.
Because you can't predict which of your company's embedded systems will fail, prioritize the systems that are the most crucial to your business, then check them out (electrical and phone systems are typical crucial systems). If you're not sure whether a particular system has an embedded processor, ask the manufacturer. If you do know which of your company's systems have embedded processors, contact the manufacturers to find out how well their systems will handle the Y2K change, or whether the systems must be updated. If manufacturers of embedded systems want to survive the legal morass that follows the millennium party, they will be deeply involved in testing their systems. (For more information about Y2K legal matters, see the sidebar "The Legal Case.")
Planning
Now that you've taken inventory and assessed your Y2K problems, step back a minute. Look at your company as a whole and determine which of your business processes are mission-critical. Map out all your processes and prioritize them so that you can approach your Y2K conversion in a systematic way.
It's unfortunate but true that your most business-critical processes are probably the only ones you can save from Y2K disaster before 2000. However, you must still identify and map your business processes so you can make contingency plans. For example, unless you check your supply chain for Y2K compliance, you can't know whether it might fail. But if you know that problems are likely to befall your supply chain, you can arrange for back-up suppliers in case the chain breaks on January 1, 2000.
Next Month
In Part 2, I'll describe steps 5 through 8 of your Y2K conversion project. If you're beginning to think this project is an enormous undertaking, you're correct. That's why it's essential to begin today.