Charles Dickens: "It was the Best of times. It was the worst of times."

In the Trenches with LAROKE

Konsultant's Log, Cyberdate 06.14.1997 (When it rains, it pours)

SITREP: Wednesday, May 28, 1997 I awoke at 4 AM to get ready to go to the office by six, my usual practice. A terrific thunderstorm had brought me to near wakefulness several times during the night. It was the remnants of the monster that had devastated Jarrell, Texas the day before. "Renegade", my jeep, had a dead battery and I was driving "BillyBob", my '55 chevy pickup truck this week.

BillyBob is in fine mechanical condition but needs a lot of bodywork and rubber seal replacement at this point. Some person who owned BillyBob before my brother, Krash Jr., got him, lined the cab with this ugly, blue, seventies retro, shag carpet. All this stuff gets wet when it rains and driving with the one working vacuum-powered wiper slowly scraping the windshield is like steering a mushroom barn through a waterfall. This was what was running through my mind as I got dressed and fed "Wingnut" (the parrot).

It wasn't raining anymore when I stepped out of my apartment, so the ride was much more pleasant than anticipated. I got the lights on at the office and the first of many pots of coffee brewing before sitting down in front of "HAL" (my PC) and enjoying my last few moments of blissful ignorance, before discovering that the storm had wreaked havoc on our network system.

HAL is on twenty-four hours a day. He is set up with the IBM Aptiva "Ringcentral" Voicemail and Fax software. I only turn the monitor off when I go home. After the monitor warmed up, I noticed the Mouse Cursor was frozen. Keyboard commands were also ineffective. I tried the "three-fingered salute" (CTRL+ALT+DEL) for a warm reboot. Nothing. Like many new PC's, HAL does not have a "Reset" switch (this is something I really miss, along with keyboard locks), so there was "nothing for it" but a cold reboot.

Turning HAL off, waiting a few moments and turning HAL back on produced a normal bootup (as far as I could tell) up to the point of the Microsoft Network Login Dialog. The mouse was still not working, but I could manouver through the dialog box using keyboard commands. After entering the required password information, "Tabbing" to the "OK" button, and pressing the "Enter" key, HAL attempted to connect, unsuccessfully, to the computers "P2" and "Old Blue" through the company network.

TACAMO: It was time to put on my "Sherlock Holmes" hat. P2 hadn't been started yet, so it was natural that HAL couldn't connect to that PC, but Old Blue, the file server, operates twenty-four hours a day, same as HAL, and the network connections should have been established.

I decided to start P2 next. P2 connected to Old Blue without problems, but could not find HAL. Upon switching to Old Blue, I found it's mouse cursor frozen, like HAL's. Unlike HAL, Old Blue still responded to keyboard commands. Using the "Shutdown" dialog, Old Blue was restarted. Old Blue's reboot process halted early with a system "FDD Controller Failure" error message. This was not a good sign, but the bootup was allowed to continue after pressing a keyboard command. I was concerned because the "Floppy Disk Drive" controller circuitry resided on the same SCSI adapter that controlled Old Blue's fixed disk drives. Like P2, Old Blue could not make network connections to HAL. Old Blue's mouse still did not work, but I was able to set the server functions up by keyboard. I left Old Blue "limping along admirably" while I turned on the other PC's in the network to determine the extent of the damage.

After starting the other eight machines in the network, all of which appeared to bootup normally, A DOS network diagnostic program was loaded on "Merlin", a PC in the clerical area. After watching the results of this program for a few minutes and seeing nothing "out of whack", I returned to my office where the damage seemed to be concentrated.

HAL's mouse is a cordless mouse that works using radio signals. After "fiddling around" with the channel (frequency) buttons and resetting the receiver, the mouse began to work again. This brightened my mood considerably. Using the keyboard to navigate Windows 95 when you don't have the keyboard commands memorized is a "teeth-gritting" exercise.

Knowing that the Microsoft Network protocol was not working on HAL, it was time to test for the other installed protocol, TCP/IP. Microsoft Internet Explorer was started, and the company intranet home page URL was typed into the address field. HAL failed to find the intranet address which led me to believe HAL's Network adapter card might be malfunctioning.

HAL's LAN adapter card is a Linksys Ethernet adapter (See In the Trenches Installment 6 Cyberdate 04.19.1997 for the ugly details of making this work with the existing Invisible LAN network). Since I had a couple of spare Linksys adapters of the same type, It was time to open HAL up and replace the suspected malfunctioning card. Before commencing surgery on HAL, I replaced the BNC "Tee" connector that connects the adapter to the "thin coax" network wiring to eliminate it as a suspect. This did not do any good, so I put the old connector back.

The Linksys adapter is not a PnP (Plug and Play) card, so I opened the Windows 95 Device Manager on HAL to jot down the IRQ Interrupt and I/O address settings for the current Linksys adapter which were 10 and 0300h-031Fh, respectively. This would allow me to setup the replacement adapter with the same settings before starting Windows 95 again (Windows 95 would restart without triggering new hardware configuration problems).

HAL was shut off and disconnected from the network. It took only a few minutes to remove his case and replace the Linksys adapter. HAL was reconnected to the network and started. When the "Starting Windows 95" message appeared on the screen, I pressed the "F8" function key to get a menu of startup options. "7. Safe mode command prompt only" was chosen to go directly to the DOS prompt without loading any drivers.

I put the setup utility diskette that shipped with the Linksys adapter in drive A: and ran the utility program which allowed me to override the default Interrupt and I/O address settings with the settings I had recorded from the Windows 95 Device Manager. The utility saved these new settings to the Linksys EEPROM and, after removing the diskette from drive A:, I rebooted HAL. This time, after entering my password at the Microsoft Network Login Dialog screen, HAL found, and connected to, Old Blue and P2 just the way he was supposed to.

One down and one to go. My co-workers were beginning to arrive by this time, and as long as Old Blue was performing his network server duties in his krippled state, I was content to troubleshoot his problems later.

In early afternoon I tried to print a document from HAL to the TI Microlaser printer connected to Old Blue. The document went to Old Blue but never printed. I got the feeling Old Blue couldn't wait any longer to be fixed. I switched over to Old Blue's monitor and found that the Windows 95 Print Manager was hung-up trying to print to the LPT1 port that the TI Microlaser was connected to. The printer's LCD readout indicated that it was online and ready to go. This situation gave me enough klues to guess that the multi-function I/O card, to which both the printer and Old Blue's mouse were connected, might be acting up.

Working my way to the Windows 95 Device Manager on Old Blue via keyboard and profanity, I found the Floppy Disk Drive controller, Mouse and printer ports disabled. Except for the FDD controller, this supported my theory of a bad I/O adapter. I keep spare generic I/O boards around since they are relatively cheap (under fifty dollars). It was time to take Old Blue off-line and open him up. Before leaving the Device Manager I recorded the Interrupt and I/O address settings for the disabled COM1 mouse port (IRQ 04, I/O Address 03F8h-03FFh) and the disabled LPT1 printer port (I/O Address 0378h-037Ah). This information would allow me to configure the new adapter to match the old adapter and avoid resource conflicts the same way I had with HAL's new Network adapter.

Old Blue was shutdown after informing everyone the server would be going offline for a while. Old Blue normally sits in a fairly inaccessible corner of my office. More profanity and some grunting was employed in getting him disconnected and moved to my work area. Pulling out the I/O board, I noticed that it's main chip was "burnt and bubbled", a sure sign.

Before putting the new I/O board in Old Blue, it had to be configured. This card was not PnP enabled, nor did it have a software configurable EEPROM as the Network adapter did. This was an older technology "roll your own" DIP switch and jumper block type board. For those of you that are fairly new to the world of PC hardware setup, this is how all boards were setup in the pioneer days four or five years ago. Dip switches are very small toggle switches that you set with a small screwdriver or the tip of a ballpoint pen (this is probably the most important use of all the pens you see crammed in the typical computer cowboy's pocket protector). DIP switches usually come in groups of four or more. Jumper blocks are a cheaper method of accomplishing the same purpose, that is enabling or disabling a circuit. In the case of jumpers, there are two or more "pin" contacts sticking up from the circuit-board, and the jumper block is placed on two pins to close a circuit. The new I/O card was set up with one serial port (COM1} and one parallel port (LPT1) with the above settings I had written down from the Device Manager. All other ports on the card were disabled.

Now that the new I/O adapter was configured the same as the old card, it was placed in Old Blue. All of Old Blue's wiring connections were restored, and he was placed back online. Old Blue started normally. There were no FDD Controller failure error messages, and when Windows 95 came up, the mouse was working again. Viewing the Device Manager showed everything to be in working order. It's still a mystery to me why the fried I/O card disabled the FDD Controller, but I'm not going to question good fortune at this juncture. Finally, a document was printed with the TI Microlaser. The entire system was back to normal as far as I could surmise.

MISREP: Even though both HAL and Old Blue were protected by UPS (Uninterruptable Power Supplies), they were connected to other, less well protected, parts of the network also. The network cabling does not have surge protection, and the laserprinter is not protected by the UPS because it uses too much power.

The system is only as safe as the cheapest surge protector. In this case, my best guess is that HAL was damaged through the network cabling, and Old Blue received a zap via the printer port, but I don't really know.

Funding currently prevents me from applying all the safeguards to the system I would like, but I've got lots of company in that boat, and I'll continue to "soldier on"..

LAROKE Microcomputer Consultants
155 East Boca Raton Road
Boca Raton, Florida 33432
(561)368-0659 (Tel & Fax)

Issued Saturday, June 14, 1997

Updated Tuesday April 14, 1998

copyright © 1996-1998 LAROKE Microcomputer Consultants all rights reserved