People have begun to complain about the Year 2000 (Y2K) problem. "We didn't create this situation. Why should we have to pay for it?" "Two-digit year fields with the millennium coming? What were those programmers thinking in the 1960s and 1970s?" I'll tell you exactly what those programmers were thinking. I know, because I was one of them. What we were thinking was, how can we get this application and several others to work on a 32KB machine? (We are the programmers who, to this day, will inform you that 1KB is not 1000 bytes--it's 1024 bytes.) Conserving bytes mattered in those days, because MB systems did not exist. Those century digits were bytes we could save--so we did.
No matter what caused the problem, today's pressing concern is that only about 16 months remain before 2000 arrives. Are your systems ready? A recent study by the GartnerGroup determined that 30 percent of US businesses haven't begun to consider how the Y2K problem will affect them. That's a frightening statistic when you realize how dependent on computerized data our information-based society is. In this two-part article, I will walk you through an eight-step approach to solving the Y2K problem in your organization. If you've already begun getting your systems ready for January 1, 2000, you can use these steps as a checklist of essential action. If you don't think Y2K will pose a problem for you, follow the steps to prove it. Should you discover you're not as safe as you thought you were, you'll know how to begin fixing your problem and develop contingency plans.
The Eight-Step Approach
A comprehensive approach to the Y2K problem involves eight steps. Let's take a quick look at the steps, then I'll discuss each one in depth.
Step 1: Awareness. Before you can fix a problem, you must recognize that a problem exists. Some systems will fail on January 1, 2000. However, which systems will fail is anybody's guess. With careful testing, you can remove some of the guesswork from the situation in your company.
Step 2: Inventory. Before you can do anything about the Y2K bug, you must take a complete inventory of your hardware and software. When I suggest you take an inventory, I don't mean the kind in which you determine that you have 34 PCs, 34 copies of Microsoft Word, 12 copies of Microsoft Excel, and a homegrown accounting system. I mean compiling a complete and detailed list of all your data processing resources and the systems they connect to.
Step 3: Assessment. After you have your inventory of resources and systems, you must check every item on the list for Y2K compliance. This process involves inhouse testing of individual hardware units, contacting manufacturers to verify their software's Y2K compliance (then testing the software anyway), and checking custom code line by line for obvious and hidden date usage. (Some currently available Y2K assessment packages can help you check custom code. Table 1 lists some of the available Y2K tools and services.)
Step 4: Planning. You need to devise a strategy for fixing the Y2K problems you discover in the assessment stage. Business-critical processes come first, because the likelihood is strong that you won't have time to fix anything else. In fact, prioritize your business-critical processes--because you might not have time to get to all of them.
Step 5: Remediation. Focus all your MIS resources on fixing as many of your business-critical processes as possible. (Y2K conversion packages exist to help here, too.) Use your priority list, because unless you have a very small company, you probably won't have enough time to fix everything. Don't try to implement new projects until after you've completed and tested your Y2K project.
Step 6: Testing. After you've fixed the business-critical functions, you need to unit test, package test, and system test. Many large companies have determined that they must complete all their coding changes by January 1, 1999, in order to have enough time to thoroughly test the changes. You'll need to spend two to three times more time on testing than you took to fix the problems you found.
Step 7: Integration. When your systems test cleanly, you need to integrate all your systems and test functions and interfaces both inside and outside the company. You must be certain that the changes you made to bring one system into Y2K compliance don't crash another system. You must also be sure that you can still pass information to and from suppliers, regulators, and customers.
Step 8: Contingency planning. The most important step is to devise plans that answer the "what if?" challenge. What if your company has more Y2K problems than you thought? What if you don't complete your project on time? What if you missed something? You must establish alternatives to your current dependence on computers, and you must do it before January 1, 2000--just in case.
Awareness
The scariest statement I've heard lately is, "We're running Windows NT; we don't have a problem." Such unwarranted optimism can cost you in lost business, angry customers, and potentially disastrous lawsuits. It can also bring your business to a grinding halt at 12 a.m. on January 1, 2000.
Is NT safe from the Y2K bug? Simply put--no. It's true that Microsoft designed NT with a built-in 4-digit date field, and primary vendors are busy releasing Y2K-compliant software updates and hardware. It's also true that NT, unconnected to other systems or networks; running on current, standard, brand-name equipment; and using only current, standard, brand-name applications, might be safe. However, the perfect NT scenario fits almost no one.
Nearly every business has cloned equipment, custom applications, modified applications, homegrown utilities, or old hardware; software that's one or more releases behind the current version; legacy systems from the 1970s and 1980s; heterogeneous networks with various switches, routers, or hubs; or business (and network) connections to some other company that does. NT won't protect you from problems on a system whose hardware or firmware can't handle century digits, it won't protect you from 2-digit year field problems on legacy systems you connect to, and it won't protect you from Y2K problems coming from other systems you connect to.
Inventory
To get a true picture of the extent of your Y2K problem, you need to take a detailed inventory of your hardware and software, including shrink-wrapped applications, proprietary utilities, and major systems. Most of the major NT systems management packages, including Microsoft's Systems Management Server (SMS), Tivoli Systems' Tivoli Enterprise, and HP's OpenView, inventory hardware and software. Computer Associates' Unicenter TNG inventories only software.
To inventory hardware, you need to know brand name, processor type and speed, internal and external peripherals and their attributes (such as brand, size, and speed), and licensing dates. You must track down and list network connections for every piece of computer hardware your company uses, whether you own, lease, or borrow that hardware. If some of your employees use their personal computers to interface with your system, you must also list those systems.
If you don't have a hardware inventory package, BindView's NETinventory inventories your hardware to the level of detail you specify. NETinventory can tell you everything you ever wanted to know about the nodes on your network--from machine, processor, and bus type to physical disk configuration and partition information, to BIOS information and Ethernet card manufacturer and configuration. If you can think of something you'd like to know about your hardware, NETinventory can probably give you that information.
To inventory software, you must know version numbers, licensing dates, expiration dates, and which PC is running which version of which product. You need to know which systems are running mission-critical applications and which systems contain inhouse utilities. You also need to know who made the most recent changes to your software and when--whether these changes were vendor patches or inhouse fixes.
You can use NETinventory for software inventory, too. It provides statistics such as product name, vendor name, version number, category, number of copies of the product, and serial numbers. NETinventory also reports on mystery software packages and tells you where they are so you can identify them. Some software packages call themselves inventory solutions when what they do is list where in a particular program certain date problems exist--these packages don't identify programs and program characteristics. Such solutions can be useful for assessment, but they aren't thorough enough for adequate inventorying.
Assessment
Now that you know exactly what your company hardware, software, and networks comprise (including all interfaces you have with other systems and networks, such as EDI handoffs or software upgrade interfaces), you must determine the extent of each component's exposure to the Millennium Bug. Take your hardware and software inventories in hand and prepare to check every item on those lists.
Testing hardware. Many systems administrators automatically react to Y2K as if it's a software problem that adjusting a few date fields and perhaps making a few calculations will take care of. However, on January 1, 2000, PCs or network hubs or disk drives could fail. The root causes of such hardware failures might be licenses that expire, a chip that equates the year 00 with the chip's origin date, an improperly cycled CMOS realtime clock (RTC) date, or incompatibilities between the system and BIOS dates. (Keep in mind that BIOS's in computers bought at the same time from the same manufacturer can handle dates differently.)
Begin the hardware testing process by checking the license expiration dates on all hardware and software agreements your company has. If any licenses expire before 2000, you must update them or replace the affected hardware or software with an updated version, because cycling the clock ahead to 2000 in the following tests I describe can take your system past any license expiration dates and bring it down. If your system is dead, you can't reset the date and restore from backup, so be sure to take a complete system backup before you test. Finally, if a system exhibits strange behavior during testing, set the date back to the current date before you reboot.
Two tests are available for use on your PCs to check the RTC (for step-by-step directions for conducting these tests, see the sidebar "Check the RTC," on page 129). The first test determines whether the clock will cycle properly to January 1, 2000, and the second test determines whether you can set the clock to 2000. Many PCs won't pass either test, because their CMOS century digits don't cycle properly.
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 4GLsÂinstead 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.
