Hurricane Y2K is coming, and you need to batten down the hatches. You don't have time to build an underground shelter or move inland. You have to stay put and ride it out.
Windows NT users might think they're safe from Year 2000 (Y2K) problems. They might have the mistaken idea that NT is Y2K-compliant. Now is not the time for complacency. If you sit in your lawn chair and watch everyone else scramble around to protect themselves, the survivors will be picking you out of the debris after Y2K hits.
Many people think the Y2K problem is simply a two-digit vs. four-digit date problem. In fact, the Y2K problem is a suite of related problems:
- Four-digit dates: Most hardware and software cannot acquire, store, compare, or calculate four-digit years.
- Transitioning from 1999 to 2000: Most hardware and software cannot transition smoothly from 1999 to 2000. The system follows 1999 with 1900, 1980, or another anomalous year.
- Leap years: Years that don't end in 00 and are divisible by 4 are leap years. Years that end in 00 are leap years only if they are divisible by 400. Many hardware and software systems don't test for divisibility by 400 and thus don't recognize 2000 as a valid leap year and February 29, 2000, as a valid date.
- Magic dates: Programmers often used certain dates (e.g., 9/9/99, 12/31/99) to indicate infinite time in the future. These signal dates will become real by January 1, 2000.
Y2K problems are compounded because Microsoft has been slow to release information about its products' Y2K compliance. In addition, no official (i.e., independent) definition of Y2K compliance exists. Microsoft has issued a definition on its Y2K Web site (http://www.microsoft.com/year2000). This definition has serious implications for users. (For more information about Microsoft's Y2K-compliance statement, see the sidebar "Microsoft Y2K Compliance".)
Microsoft has five categories of Y2K compliance: compliant, compliant with minor issues, not compliant, testing to be completed, and will not test. Each NT version falls on a different place on this scale.
NT 3.51 is in the testing to be completed category. Microsoft was supposed to complete NT 3.51's Y2K-compliance testing during the summer of 1998. At press time, the company hadn't finished the testing. Cynics believe Microsoft is trying to force users to upgrade from NT 3.51 to NT 4.0, which is the current version. If you're still running NT 3.51, you need to install Service Pack 5. SP5 fixes some of NT 3.51's known date problems. You can download SP5 from http://support .microsoft.com/support/downloads/LNP391.asp.
NT 4.0 is compliant with minor issues. Some of NT 4.0's problems are that User Manager does not recognize 2000 as a leap year; the Find File feature miscalculates the date display for years after 2000; and the Date/Time applet in Control Panel sometimes displays the wrong day (i.e., the system date is correct, but the display date is off by a day). These problems are minor. A larger problem is that NT 4.0 recognizes years only through 2036.
To ensure NT Server 4.0 and NT Workstation 4.0 Y2K compliance, install Service Pack 3 (SP3) and the Y2K hotfixes. You can download SP3 from ftp://ftp.microsoft.com/softlib/mslfiles/nt4sp3_i.exe, and you can download the hotfixes from http://backoffice.microsoft.com/downtrial/moreinfo/y2kfixes.asp. NT 4.0 also requires a hotfix for Internet Explorer (IE) 3.02. You can download this hotfix from http://support.microsoft.com/support/downloads/PNP370.asp. Finally, NT Server 4.0 requires Microsoft Site Server 3.0 for Y2K compliance. You can download the beta version from http://backoffice.microsoft.com/downtrial/moreinfo/siteserver3.asp.
Despite NT 4.0's problems, it is the operating system (OS) of choice to survive Y2K. Many enterprises are migrating their systems from other OSs (including Windows 3.1) to NT. This trend is increasing the demand for NT-savvy employees. In addition, many enterprises use NT to test and fix their noncompliant applications from other systems. Programmers port their code to NT platforms, test and fix the code, then port it back to the original system. The 64-bit timestamp in NTFS is a benefit because it permits dates through 2108, giving you plenty of time to upgrade to Windows 2000 (Win2K--formerly NT 5.0).
Microsoft promises that Win2K will be Y2K-compliant, with no service packs, patches, or minor problems. But the question is, "When will Microsoft release Win2K?" The first beta has been out since last winter; Microsoft released the second beta in second quarter 1998. Microsoft maintains that the final release is on track for early 1999.
Regardless of which version of NT you use, you can take measures to protect your system from the Y2K problem. First, increase your system's four-digit date awareness. Open the Regional Settings applet in Control Panel, select the Date tab, and change the date format to long date. For example, select dddd, MMMM dd, yyyy to display Thursday, April 22, 1954; MMMM dd, yyyy to display April 22, 1954; dddd, dd MMMM, yyyy to display Thursday, 22 April, 1954; or dd MMMM, yyyy to display 22 April, 1954. You can also use a Registry editor to configure long dates. Go to HKEY_CURRENT_USER\ControlPanel\International and select sLongDate. When you use a Registry editor to configure long dates, the display date might change by a day. SP3 for NT 4.0 fixes this problem. Open the Date/Time applet in Control Panel to verify that the system date is correct.
Second, stop using two-digit shortcuts and start entering years as four digits. Open the Regional Settings applet in Control Panel, select the Date tab, and change your short-date format to display four-digit years. The four-digit format is important in DIR commands, shell files, and certain Win32 applications. (Test your Win32 applications to see if they use four digits to display years.)
Quick Y2K Fixes
If you haven't started working on the Y2K problem, now is the time. You have only one year left before the year 2000, so you need to concentrate your efforts on mission-critical applications and applications you can fix quickly. Establish a triage procedure to determine which applications are a priority and which applications are beyond help at this point. (For complete solutions to the Y2K problem, see Jane Morrill, "Year 2000 Mission Control, Part 1," September 1998, and "Year 2000 Mission Control, Part 2," October 1998.)
With only a year to solve the Y2K problem, you cannot consider all solutions. For example, you don't have time to implement the only surefire Y2K cure: expanding all year references to four digits in all code. You can consider only a few Y2K solutions.
Inhouse applications present special problems. You can use programs that search your code for year references and fix them automatically. You will then have to test the results manually to verify Y2K compliance. Take advantage of the automated analysis, remediation, and testing tools that are available for NT. (For information about these tools, see Jane Morrill, "Year 2000 Mission Control, Part 1," Table 1, September 1998.)
Another method of fixing inhouse applications is year shifting. You shift all years back by the same number, usually 28 (to preserve leap years). Thus, the actual year 2000 becomes the computer year 1972. Years maintain the same relation to one another, because all years shift. An automated system then lets you change real-world years into computer years (by subtracting 28) and computer years into real-world years (by adding 28). I don't recommend this stopgap measure because it only delays the problem without fixing it.
A better solution to fixing inhouse applications is to replace them with compliant commercial packages. Implementing existing Y2K-compliant applications will save you time. NT users can find a variety of compliant commercial applications. If you are using commercial applications, upgrade to a Y2K-compliant version. Software vendors are working feverishly to provide Y2K-compliant software packages.
Evaluate your company's needs and consider retiring noncompliant applications. If an application is not crucial to your company's operation, it is not worth your time to upgrade.
Doomed by Dependence?
Despite running a compliant OS with compliant applications, you might be doomed to Y2K problems. You must carefully examine your IS environment to evaluate overall Y2K compliance. For example, if you run NetWare and NT, you must ensure that NetWare's Y2K-compliance problems won't affect your system. You must consider the compliance of hubs and routers, Internet connections, and firewalls. You need to evaluate noncompliant outside data, such as data from extranets with suppliers. Bad data from an external source is worse than bad internal data because you cannot fix external data. You do not want outside forces to affect your compliant NT system.
Making your NT system Y2K-compatible will pay off. You already see the hurricane coming, so make plans now to survive it.