Zen in the art of troubleshooting.

·期刊原文

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.