AND THE WINNER IS? - Part II

by Wayne M. Krakau - Chicago Computer Guide, March 1996 - NewsWare, September 1996

This is the continuation of the presentation of my own series of awards, the SI (for System Integration) Awards. Last month I covered the positive categories. This month I’ll cover the negative categories. As I previously stated, it’s my award, so I make all the rules, create the categories, nominate the candidates, and choose the winners - and if you don’t like it - tough!

The third SI Award is The Joseph Stalin Award for Spreading Misinformation During a Technical Support Call. It goes to Palindrome Corporation, for claiming in their final statement that certain Adaptec controllers were not only NOT officially "Novell Approved", but that they were never designed to be used in a NetWare environment. Since both Novell and Adaptec agree that the controller in question is approved for use with NetWare, the controller’s documentation contains whole chapters devoted to NetWare installation, and the product’s box is plastered with "Novell Approved" stickers, I consider Palindrome’s assertion such a huge piece of misinformation that the old fact-bender, himself, Joe Stalin, would have been proud.

Did you notice that I used the term "final statement"? That’s because of Palindrome’s previous declarations, which were fairly outrageous, but not quite award-winning. This includes declaring their lack of support for a particular controller after repeated extended discussions of how to use their software with that controller. It also includes an after-the-fact assertion that the mere presence of this controller would cause their software to malfunction, even if that board had nothing to do with their software.

Since I have already documented these events in detail in a previous column, I won’t go into the particulars of this incident, however, I will note that the people at Adaptec were definitely not pleased about this affair.

The fourth SI Award is for The Automated Phone System From Hell. This award had many candidates, but a late entry from Iomega Corporation simply outclassed the rest. It is a system seemingly taken straight out of Dante’ Inferno. All it needs is a large rock to roll uphill while waiting on hold.

Over a period of months, I had been trying to get help for a problem with one of my own systems. Over time, the gradual deterioration of Iomega’s phone system became apparent. I will admit, though, that I might have been a bit more tolerant of phone system shenanigans if I hadn’t gotten consistently inaccurate answers to my questions.

As it stands now, each menu and sub-menu within their system is preceded by its own unique, interminably long message explaining Iomega’s displeasure with your tying up of their valuable phone line and suggesting you get the hell off the line as soon as possible. (Note that this is my translation of their messages into clear English. The real messages aren’t quite as direct - but they are close.) Another underlying theme is that if you are going to tough it out and stay on the line, they are going to make you suffer for it. The general subtext is, "We already have your money, so don’t bother us!"

For good measure, the system is organized around multiple, confusing levels of menus, with no easy method of backing up if you go down the wrong path. Extra aggravation is guaranteed by delays within the menu system. When you make a selection, there are often annoying delays while you wait for the next level of response.

Throughout the system, there is no way to get to a human being either to ask which sub-menu to use to get to the right personnel, or to get a direct routing to a particular person on a follow-up call for a previously established problem.

Assuming you have a finite amount of time at your disposal, you might try searching for a way to leave a message. That would be a complete folly, since there is no messaging capability.

Also, while you are waiting, potentially for hours, keep in mind that you are paying for the call! This is what finally prompted me to give up on obtaining help. After repeated calls led only to incorrect info, I was eventually requested to purchase a new controller board for my system. The board didn’t work. Before this, I had already spent dozens of hours experimenting, using the advice given by Iomega personnel. Even the updated software that they supplied via their bulletin board system (BBS) didn’t help. The trick that finally worked was so obvious that I am still shocked by the fact that nobody at Iomega told me about it.

In an act I can only chalk up to pure stubbornness on my part, I tried to use the software that came with the new board, while still using my existing hardware. It worked! I had previously been supplied with the wrong software. After those long hours of experimentation and the frustrating sessions with their phone systems, it took only about five minutes of useful work to solve all of my problems.

Then I made the mistake of trying to contact Iomega to return the useless board. Based on my conversations with technical support people, I reasoned that the software that I ended up using was either available on their BBS for free or available on disk for a nominal fee. After repeated attempts to get through to a human, I finally had to give up after I realized that my phone bill was going to be so high that it would exceed the value of the returned board. (Hey, anybody want to buy a slightly used controller?)

The fifth SI Award is the People Who Live In Glass Houses Shouldn’t Throw Stones Award. It goes to my company, or more specifically ME, since I’m the one who screwed up. While I am only human, and, therefore, make mistakes regularly, I usually don’t do stuff this spectacular. I just found out that I generated an unrelated error while fixing a minor typo in a message line within the batch file that controls the nightly backup job for a longtime client.

This simple error, the accidental entry of a minus sign in a critical spot, caused the backup to look like it worked while, in fact, it didn’t. The batch file was designed to first back up the network drive, designated F:, starting at the beginning of the tape, thereby deleting any existing data on that tape. Then it would back up the C: drive of that workstation, appending the data after the F: drive data.

While altering one of the messages that I designed to print out between the two backup commands, I accidentally altered the C: drive backup parameters so that it started at the beginning of the tape instead of appending the data. The revised job would back up drive F:, print a message and the log file indicating that the F: drive backup was successful, then overwrite the F: drive data that was just placed on the tape with C: drive data. Then, it would print a message and the log file indicating the C: drive backup was successful. There was no indication in the log files or messages that the F: drive data on the tape had been trashed!

Somewhere along the way, I got complacent and violated my own testing standards - those same standards I have repeatedly recommended in this column and in various speeches I have given over the years. I examined the printed output and the log files and decided that was enough to establish the validity of the revised batch file. Wrong! I should have used the manual commands available within the tape drive’s software to actually view the data on the tapes. After publicly pontificating for years about the inadequate backup testing methods used within the personal computing industry, I did the very thing that I had condemned!

The scary part is that I can’t remember when I last modified the batch file. My client could have been without a valid backup for months! I just don’t know. I do, however, know that the current version of that file works. I manually checked the tape this time.

Now I can’t wait to see if this admission of humanity on my part results in a decrease in the number of calls and E-mail messages that I receive every time I write about LAN cabling, asking me for permission to violate the laws of physics so that out-of-standard cabling systems will work.

1996, Wayne M. Krakau