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.