fires to the right of me; fires to the left....

Okay. Saturday morning, I was getting ready to start work on a project that is overdue. I've planned to spend all of Saturday and all of Sunday working that project.

Saturday morning is interrupted by a phone call reporting a computer failure at work. All of Saturday, all of Sunday and all of Monday morning was spent resolving the problem.

Crashing clipper code, Odd errors from Lantastic network software, unhinged Microsoft networks, and hours of tail chasing.

The original problem, we think, was a corrupted index file on a dBase III dbf. In the midst of working the issue, a second machine running DOS 6 was rebooted. That machine failed to get on the network with an odd Lantastic error.

Many hours later, I discovered a bad port on a Linksys 24-port switch. It was always "on." Replaced the switch and the Lantastic problem was fixed. However the two machines now in the soup were in worse shape than before.

Hair pulling ensued.

Program tracing to figure out how the code was suppose to work finally led back to the corrupted index.

Now it all works.

Now my brain if fried.

This reminds me of my early Navy days in which I would spend many, many hours troubleshooting ship-wide systems with ever changing symptoms. I was always glad to get to the end of it, but if it went on too long, the level of satisfaction was insufficient to make up for the lost sleep. :)

It's been a long time since I spent much time working with compiled code or with Integrated Development Environments. I had forgotten the aspects I used to love. Step-wise debugging, for instance.

Bad Timing

I just fielded a call from a customer who was really upset. He has been unable to use CreditLinik Advantage on his laptop computer since he became a client. So he finally decided to buy a new laptop. A new expensive laptop. He got everything running the way he wanted it then installed CreditLink Advantage.

This is an application which calls into CreditLink Corp and does a bit of data exchange. No bit deal as long as the client's computer and modem fit the requirements.

He completed the installation of C/A and sent his first request about 30 minutes after our system went down. He struggled with his machine and tried over and over and over and over until he could reach us -- about 30 minutes after we came back up.

He is much happier now that he knows it wasn't his new computer or his incompetence. Whew.

I've been talking to another client who has nothing but trouble with the same software. I think her problem is related to a clash between her internal modem driver and her brand new HP all-in-one printer/fax/copier. When she installed the HP software, C/A tried to use the "new default" modem with the old modem command strings. I think. Nothing we did fixed the problem. I'm having her reinstall C/A. We will see if that helps.

Configuration Files

They are really wonderful inventions. No. Really. Around here, most of the home grown software has been compiled to expect certain files in certain places on NETWORK drives.

One machine has the same data mapped to F: and G: because she runs programs that look in one or the other.

How difficult is it to have a configuration file? A simple file that tell the app where to look.

Almost any change to the spiderweb of mapped network drives around here will cause some system or another (or many, for that matter) to stop dead. And nothing stops in an informative way. Oh no.

"Failed to open an input file" has been seen on two different machines running different programs.

Helpful....NOT.