Y2K presents problems for networks that are qualitatively different -- and more daunting -- than those facing mainframes or desktops

By Edmund X. DeJesus 11/08/99

Even as information technology managers begin to relax somewhat about the year 2000 compliance of their desktops and mainframes, a more intractable hazard literally surrounds them: their networks. It's no wonder that IT managers have left their networks for last -- networks are more complicated, more individual and tougher to test and fix than desktops and mainframes.

While frustrated at the lack of assistance they're receiving from network hardware and software vendors, these IT managers are unwilling to publicly criticize vendors they must continue working with -- so much so that every IT manager we spoke with requested anonymity. Still, nameless or not, these managers are in for trouble if their networks crash -- an outcome that Gartner Group Inc. in Stamford, Conn., estimates will strike almost one-third of networks that aren't checked and fixed.

If a date-related problem takes down a segment of an enterprise network, that enterprise may be incapable of continuing normal operations for hours, days or weeks. Still, it's not difficult to understand why networks haven't been making the Y2K to-do lists. With your desktops, you can adopt a cookie-cutter approach: Pretty much the same test-and-fix operation can be carried out on the BIOS (firmware), real-time clock and operating system of every desktop in your enterprise. Even with mainframes, you may have your million-line monster application, but it's probably written in Cobol from top to bottom.

Thousands of Items

Networks are different. You probably have thousands of items -- hardware, software and infrastructure -- from hundreds of vendors. Hubs, routers and switches have real-time clocks and operating systems with the same two-digit-year difficulties as servers.

For example, in a situation that's not uncommon, the systems administrator at a California consultancy did a simple compliance test: changing the server date to 1-1-2000 and rebooting. The result: No one could log on to the network because all passwords had expired. This administrator plans to change the expiration option to "never" at the end of December.

A LAN manager at a Denver mortgage reinsurer describes how a lengthy simulation of post-2000 dates turned up components that were stamping some e-mail with a two-digit year. The e-mail software promptly dumped all of these messages for being older than the three-month expiration date. A simple "change-the-date-to-Jan.-1-and-back" test would never reveal such a problem because it wouldn't allow sufficient time during the new century for the e-mail problem to be noticed. Although the firm has since replaced the offending unit, it intends to remove expiration controls on e-mail before the year 2000 rollover.

Overcoming Roadblocks

The first roadblock to network compliance is that it may be difficult to identify the most critical element in the system because many networks consist of combinations of different items for performing a single task. You may have hundreds of a single type of modem, but only one that handles a vital piece of traffic.

Second, some network vendor strategies often seem positively anti-Y2K. For example, it's a common -- and a commonly praised -- practice to create a single hardware platform, such as a router, and then define that platform's capabilities with firmware. That's swell for the vendor because it can create different hardware products by changing the firmware. But for the administrator trying to manage Y2K compliance, it's a disaster.

Finally, networks are complex, with many hidden implementations, such as firewalls in routers. The legendary problems involved in trying to track down a network problem become even more obtuse when there are Y2K considerations. Is it the hardware? The software? This particular software on this particular hardware?

The first challenge is to create a complete inventory of everything on your networks, including hardware, software and infrastructure. Your inventory has to be extensively detailed: That isn't just a workstation, it's a workstation with a network card of a particular brand, model and date, obtained from a particular vendor under specific arrangements.

Fortunately, there are tools designed to inventory networks automatically, and many of them are oriented toward particular platforms. For example NetInventory from Houston-based BindView (www.bindview.com) inventories hardware and software on NetWare servers, with details down to the BIOS revision level -- which you will need because the BIOS is one Achilles' heel of even recent models of servers.

Network Y2K Scanner from Tulsa-based SolarWinds.Net (www.solarwinds.net) inventories Cisco Systems Inc. devices on a network.

Novell Inc.'s Year 2000 Information Ferret is a popular, free program (www.novell.com/year2000/y2kferret.html), also for NetWare servers. NetSuite from NetSuite Development Corp. (www.netsuite.com) in Concord, Mass., is a more general network-auditing tool for compliance.

None of these tools is a cure-all. Some may not be able to use information inventoried in another tool's format. The tool may have either too little capability to be useful or so many features that its learning curve is daunting.

But once you have at least a partial inventory, you must categorize each item in terms of criticality. Highest-priority items include those that must be Y2K-compliant or the enterprise will die, such as your central facilities and your more important interfaces -- interapplication, intercompany or intranet. The second category includes items whose Y2K compliance will simplify the operation of your enterprise, such as secondary interfaces and certain departmental facilities. The last category includes everything else, whose failure will be a minor inconvenience.

Your next challenge is to investigate the Y2K compliance of each item, wading through vendor-supplied information of various levels of clarity and accuracy. "Sometimes you must actually call or e-mail contacts at a vendor to get the information you need," says Mark R. Nesseth, a contractor assisting Deluxe Corp. in Shoreview, Minn., with its Y2K efforts.

For example, users have expressed annoyance that compliance information for Microsoft Corp.'s Windows NT 4.x seems to keep changing. But according to Don Jones, Microsoft's director of year 2000 readiness, "Microsoft is committed to supporting the compliance of Windows NT 4 with Service Pack 4." This means that users need not install Service Packs 5 or 6 if their only concern is Y2K compliance -- the hot fixes to Service Pack 4 are sufficient. These same fixes are part of Service Packs 5 and 6, should users decide to install them. At this point, Jones says, only very esoteric date-related issues are emerging, such as with DOS command-line programs.

Keeping Up With Compliance

Tools make keeping up with compliance status somewhat easier. For example, Pittsburgh-based Infoliant Corp.'s Year 2000 Network Advisor (www.infoliant.com) keeps track of vendor-supplied compliance information for more than 40,000 hardware and software products. One free and useful tool is the Microsoft Year 2000 Product Analyzer (www.microsoft.com/technet/year2k/pca/pca.htm), which checks Microsoft software on Windows 95, 98 and NT 4.x.

There is, unfortunately, a large, gray gulf between "compliant" and "noncompliant." It's the "will not test" category, which includes products that a vendor has declined to determine are compliant or noncompliant. For example, a network specialist at a South Carolina university reports that many of the university's Cisco routers and switches fall into the will-not-test category. Its solution is to replace some of these components that needed upgrading anyway; the rest will be replaced if they fail.

Many users somewhat cynically regard will-not-test items as the vendor's way to generate new sales. John Earnhardt, a spokesman for Cisco in San Jose defends the practice. "We can't support all products forever," he says. Instead, the company offers its customers a free upgrade patch to software or firmware. A customer may also choose to trade in Cisco products for credit toward a compliant item.

Another peculiarity of Y2K is that the compliance status of an item can change -- and not always for the better. Some vendors have had to change the status of products from compliant to noncompliant after further testing. This is where Network Advisor can come in handy, tracking the status of thousands of items and e-mailing notification of changes.

Finally, don't assume that problems are going to vanish come Jan. 2. As Nesseth puts it, "Compliance efforts -- including tracking the status of compliance -- will continue past Y2K." Expect repairs to extend well into next year, and budget for that anticipated effort.

DeJesus is a freelance technical writer and former editor of Byte magazine. He lives in Norwood, Mass. You can contact him at dejesus@compuserve.com.

http://www.computerworld.com/home/print.nsf/all/991108CB72 --------------------------------------------------------------

You really ought to do a better job next time. Your grade goes down to F.

-- Brooklyn (MSIS@cyberdude.com), November 10, 1999

Answers

This is a great example of speculation without facts. I am an engineer who has worked on network products, and I can tell you with absolute certainty, that the networking hardware will deliver data without hesitation before, during, and after the rollover. Management of these networks might be a place where some schmuck has created a utility with date dependencies, but the low-level stuff doesn't care what day it is.

Now server software is a different story and has nothing to do with the actual hardware that allows two or more computers to communicate. Any IT manager that neglected to check their client-server sytems for Y2k compliance should get out of the industry right now.

-- You Knowwho (debunk@doomeridiots.com), November 10, 1999.

Oh, thanks, "You Know who", we of course will dismiss the entire article based on your PERSONAL CREDIBILITY AND INTEGRITY that you have displayed on this forum. Especially since the only thing that we have to lose if you are wrong is possibly everything, and if you are right, practically nothing.

LOL! LOL! LOL! LOL!

-- King of Spain (madrid@aol.cum), November 10, 1999.

The fact that you are a network engineer explains your ignorance of the overall problem facing us. Considering your lack of life experience (29 years) it is difficult to understand why would anyone take you seriously. This might sound like a shoot the messenger tirade, but cant help it after reading your posts. Why dont you read my previous post, found at http://www.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=001jtE

I understand that it will not change your position, but should you have brains, it just might force you to think.

-- Brooklyn (MSIS@cyberdude.com), November 10, 1999.

My Dear Sir Engineer

Why is it that when one of you young ones get out of school (with a diploma in your hot little hands). You all get the belief that if you wave the engineering sheepskin in the air above our heads. We'll all stare up to the heavens in awe. And await edicts of wisdom from on high.

LOL...son I have a union ticket five years older than you're apparent age! And it has been my experiencein the Electrcal feild, that the sharper a Electrical engineer gets (and they do when they pile on the experience). The more they cease to know "everything". And realize that they, as well as myself, in our chosen craft. Must and do learn things every day. Thirty years ago, there where things we were taught that where supposedly impossible to do...Today these same impossible things ARE being done.

To say you are an athority...Is telling me that you are still wet behind the ears young man, And that you still have a few more jobs to "screw up on". Before you mature.

~~~~~~~~~~~~~~~~~~~~Shakey~~~~~~~~~~~~~~~~~

-- Shakey (in_a_bunker@forty.feet), November 10, 1999.