Zen in the art of troubleshooting. (systems library techniques)

by Terry Ballard

American Libraries

Jan 1994

Vol.25 No.1

Pp.108-110

Copyright by American Library Association


"Terry, could you come over and look at this?" As university systems librarian I hear such requests seven times in an average day. Five or six of these can be, handled in seconds because they are common mishaps and the solutions are in my bag of tricks. But once or twice a day, I face the unknown and must solve a problem with a machine I know little about that won't perform a work procedure that I know nothing about. Although I nod reassuringly as a colleague describes the problem, secretly I am terrified. My problem-solving reputation is on the line. Clinging to the proper state of mind is crucial. According to Zen masters, such things cannot be written. However, Westerners rely on words, so here is a list that describes this state of mind: 1. The problem can be solved; 2. It is my job to solve it, so the buck stops here. 3. Once it is solved, that will be one more thing that I know how to do. The first tier Suppose the message on the screen reads "!![at]Memory device hung on line 44. Buffer overload exceeds density threshold." No cursor is visible and pushing the escape key does not work. The first tier of problem solving is simply turning the machine off and then on again to let it reboot. The second step is checking all of the cables. Anything that connects one part of the computer to another can shut down the whole operation if it is just a tiny bit unplugged. The final step on the first tier is turning the tables on the person reporting the problem--asking a lot of questions that are a variation on the theme of "Where does it hurt?" Caution is necessary in this questioning because it is easy to be led astray by wrong assumptions made by the person describing the problem, and a wrong turn may lead light years away from the solution. Zen and the limber mind That is where Zen comes into the picture. My wife frequently kids me about my habit of reading about Eastern religions. "You're not a Zen Buddhist. What do you think you're doing?" she'll say. Reading such material keeps my mind limber, I reply. Besides, following the Zen principle of nonattachment is a reminder to be slightly suspicious of all incoming information. Those pitfalls are there even when I should know better. Recently, I was asked to look at an OPAC terminal that had gone completely blank. "This happened right after I swivelled the machine. I think I've ruined one of the cables on the back," said the reference librarian. Turning the power off and on got no response. Then I checked the power cable on the back and found that the plug was not fully seated. Seating the plug produced a cursor, but no menu screen appeared. I went to another terminal to restart the port the malfunctioning terminal was assigned to. When I got back, I saw the welcome sight of the menu. However, the machine still would not accept commands. At that point, I accepted my colleague's notion that she had broken the cable. The terminal sat unused until the Zen side of my nature dreamed up one more thing to check. Sure enough, the phone plug that connected the keyboard to the CRT had not clicked into place. Now the terminal works just fine. Wading into the unknown Sometimes the problem does not have any easy solution. Returning to the example of the error message "!![at]Memory device hung ...... suppose that rebooting the machine brings up the same message. At that point it is time to look at the documentation of the malfunctioning equipment. Most documentation has a deservedly bad reputation, but chances are that there will be a short chapter on troubleshooting. With any luck, the problem will be described and a simple solution offered. If the documentation doesn't help, there is little to lose by taking a risk or two; it's time to wade methodically into the pool of the unknown. This usually means altering the configuration settings on the malfunctioning terminal or printer. There are thousands of permutations and combinations, so it is important that I resist the temptation to change more than one thing at a time. This is the same principle that cave explorers follow when they mark their passage. Some changes will almost certainly make the machine act worse than it did before, so I need to know how to put things back. Some intuitively talented troubleshooters break this rule and get away with it, but they aren't sure what action ultimately solved the problem. Another example from my personal Hall of Pain concerns the transfer of records in our cataloging department. I had set up our OCLC terminals with function keys that automatically send a two-screen record to our local system. Sometimes a record would hang up after the first screen was accepted. I couldn't solve the problem, so I put it out of my mind. Months later the problem came up again. I asked a library assistant to show me another example. "But you said it was impossible to fix," she reminded me. In half an hour we had isolated the problem and fixed it. The system had received the information but did not know it. The fix was just a matter of sending the interface unit something that would satisfy its search for a second screen without adding anything to the record. With intermittent problems, the main challenge is finding out what the problem really is. Once you find out what is different about the thing that malfunctions, it is usually easy to fix. Accepting uncertainty Sometimes things will return to normal before you figure out what went wrong. I call this the "uncertainty factor" and have learned to just accept it. A problem is quickly forgotten unless the machine does the same again within a few days. I don't feel that I have to know every aspect of a problem--especially if the problem disappears. Often after quick fixes, people ask how I did it. I mutter about fooling with the connections and prodding the thing. "But I did that!" they exclaim, and then they wonder if my job has an element of magic. It is useful for people to believe this. There seems to be a greater chance of success if the person believes that the machine will work as soon as I look at it. However, I must guard against believing my own clippings. The solutions for long-term problems often prove to be simple--so simple that I could kick myself later. One of my favorites was a machine in the acquisitions department that could not be used for check-ins. When the check-in box appeared, the data would start to fall apart. We checked the settings repeatedly, and they were identical to the other machines in acquisitions, even though the balky machine was an earlier model. Swapping cables with the machine on the next desk didn't help, proving that the problem was with the machine itself. In desperation, I tried changing the terminal emulation. This seemed to affect the check-in boxes. The machine could not handle the terminal emulation it was running, but our acquisitions system couldn't run anything else. Finally, the terminal was swapped with one linked to the cataloging and circulation system, which can be set at VT100 terminal emulation. It has worked perfectly ever since. When a piece of equipment is broken, the only procedure is to send it out for repair. However, I have found that only one percent of my cases need to be sent out. As someone with no technical background and little formal education in computer science, I feel pretty good about that score. The point is not that I am an extraordinary troubleshooter--it's that if I can learn to do this anybody can. Buddha-nature I could offer more examples, but more might cloud the issues and thus tell you less. The above statement is similar to a Zen koan, a kind of puzzle Zen masters give to students to make them think beyond their normal frame of reference--and to drive them crazy. The modern equivalent is minimalist comic Steven Wright's story about buying a cordless extension cord. One of the most famous Zen koans is the question, "Does a dog have Buddha-nature?" I suggest you meditate on these questions: Does a systems librarian have Buddha-nature? Does a computer? But first, you must hear the rest of the famous koan concerning dogs: "If you answer yes or no, you lose your own Buddha-nature." Parallels between Zen masters and systems librarians: Zen Masters Systems Librarian GOAL Satori--the state of Solving the problem perfect enlightenment. so I can go back to reading my e-mail. METHODS Meditate to achieve Play with things a blissful state. until they start working Think about Zen koans: Read the manual: impossible sounding impossible sounding. puzzles that lead to a directions that lead state of no-mind. to the state of no-luck. Being hit with a stick. Hitting the computer with a stick. Fasting. Eating. SURVIVAL Gong into the village Going to the peer with a rice bowl review committee and begging. and getting tenure. SECRETS Share your knowledge Let your secrets with a select group of go to the grave young monks. with you. TERRY BALLARD, assistant professor and systems librarian at Adelphi University in Garden City, N.Y., was an English major.