First Steps to Y2K: Hardware Solutions

There are a number of ways to tackle your own and your clients' potential Y2K problems. Let's start by breaking the potential culprits into software and hardware. We'll look at the latter first, because in many ways it is the easiest to handle.

Hardware problems usually involve embedded device controllers such as BIOSs, CMOSs (Complementary Metal-Oxide Semiconductors), and dedicated ASICs (Application-Specific Integrated Circuits) placed on motherboards. Many controllers have date functions built into them either for timing, reporting, or control purposes. Whether these controllers have a problem with Y2K depends not so much on the programmer's talents when they burned the controller as on the purpose of the device. Let's face it: your microwave is not going to let your popcorn pop for 100 years if you start popping late December 31st. Devices like these use dates and times, but only as counters. On the other hand, some computer and network devices like routers and gateways may report inaccurate statistics (or even stop working) if the controller can't handle the wrap-around of the year properly.

Let's start by alleviating your concerns: the vast majority of computing devices with embedded controllers are Y2K safe. This applies whether you just bought the latest model or a customer has had one for a decade. Embedded controllers need to have tight coding, sure, but most device controllers can handle yearly wrap-arounds, including the one from 99 to 00 without problem. Some devices use four-digit years specifically to allow Y2K handling, and many that use two digits have algorithms that can tolerate the change. Of the thousands and thousands of network devices and computers on the market, the number with known Y2K issues is very small.

Solving Y2K hardware problems requires one of three approaches: ignore the issue and hope the device doesn't care; replace the device with a newer Y2K-compliant model, or; upgrade the controller software. For many computers and network peripherals that VARs have to deal with, controllers use a flash-BIOS system. Flash BIOS allows new software to be loaded into the controller from a floppy or network device, replacing the older system's instructions. Good examples of such devices are flash-BIOS equipped computer motherboards and network cards. I just upgraded several of my ALR servers with new BIOSs, and the procedure couldn't be simpler: download the new release onto a bootable floppy, reboot the machine from the floppy, and run a utility that uploads the new BIOS to the motherboard. Total time for upgrade, about two minutes. The same applies to a bunch of network cards I upgraded, too. With flash-BIOS, the device manufacturer can work around little issues like Y2K as well as patch bugs, support new protocols, and generally enhance the device. Flash BIOS costs more than older one-burn BIOS systems, but in the long run costs manufacturers less because they don't have to ship upgraded BIOS chips to customers. It's up to you to install the flash BIOS patches, but this is an easy solution to the Y2K problem. (Most flash BIOS equipped system won't need Y2K patches as the devices are usually new enough to have the date handling system correct, anyway.)

Replacing the controller chips themselves (such as a BIOS) will be necessary on many older network and computer peripherals, as flash BIOSs are expensive and not considered necessary for many of these devices. Assuming the device manufacturer makes an upgrade available, you need only power down the device, yank a PROM or EPROM from its socket, insert the new one, and reboot. Problems naturally crop up when the manufacturer is out of business or won't support older hardware any more, in which case you are most likely out of luck. But then again, bear in mind that most hardware doesn't care about the Y2K wrap-around, anyway, so this may be a moot point.

The ignore-it-and-hope-it-doesn't-matter approach will be adopted by a lot of people. As I've pointed out, most devices won't care about the date change, but there are some that do. Ignoring these devices will have different effects, depending on the device's purpose. For network devices, the most common problem is a screw-up in statistics and trouble reporting with protocols like SNMP (Simple Network Management Protocol). Some devices I've tested by rolling network dates forward have simply given erroneous data for the time-span over midnight Dec 31, then kept on going just fine after that reporting period. None of the hardware I've Y2K tested has refused to work after the roll-over.

If your clients are wary of the Y2K problem you can always recommend replacement of the device with an updated model. This will not only take care of the Y2K issue (hopefully!) but also provide a more current (and hopefully faster or better) device at the same time. Few clients are willing to replace huge chunks of their networks or other hardware on the off-chance a Y2K issue will arise, though, so this alternative is not going to be taken by most customers.

If you are concerned or what to reassure your customers that their hardware is Y2K-safe, you can check the manufacturer's Web sites. Many are posting compliance statements for their devices, or in a few cases, notifying customers of upgrades necessary. Some testing labs are also doing Y2K compliance summaries now, so you can check the larger network magazine sites for details. Next column, we tackle the thornier issue of software.