首 页  |  中国禅学  |  禅学三书  |  慈辉论坛  |  佛学论文  |  最新上传  |  文学频道  |  佛缘论坛  |  留言簿   |

 管理登陆        吴言生 创办              图片中心    关于本网     佛教研究所 主办


  • 哪种人福报最大?[111]

  • 5000字的《金刚经》总结出6个字[129]

  • 做再多的功德,不如去做这一件[169]

  • 最基础的佛教基础知识,佛弟子[140]

  • 这8部经典佛经,你都读过吗?[125]

  • 无事此静坐[146]

  • 弘恩法师:看一个人修行好不好[128]

  • 想太多,就是折磨自己[103]

  • 学佛让生命放出异彩[131]

  • 人生在世,不去了解佛教是一件[128]

  • 原来,这就叫“不值得定律”[131]

  • 因果有时虽然看不见,但会以不[115]



  • 本站推荐

    做再多的功德,不如

    中国"观音学″与"中

    中国"文殊学"与文殊


       您现在的位置: 佛学研究网 >> E3英文佛教 >> [专题]e3英文佛教 >> 正文


    Zen in the art of troubleshooting.
     
    [ 作者: Terry Ballard   来自:期刊原文   已阅:16530   时间:2007-1-16   录入:douyuebo


    ·期刊原文


    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.
        
       
               
               
         
       

     

     

     【关闭窗口
    相关文章:
  • 禅宗的机锋与棒喝[132]

  • 惠空法师:从禅、净兴衰思考中国佛教之未来[217]

  • 禅,与身心对话的艺术[351]

  • “宅”也是一门艺术 给生活一些改变[321]

  • 修行不一定要打坐,可是打坐能帮助你修行[429]

  • 禅宗现代转型的发展路向及其启示[476]

  • 禅宗的特色、作略和风格[515]

  • 现代禅学顿渐关系的重构及其取径与概念[550]

  • 刘禹锡的诗与禅[494]

  • 禅宗与中国传统士人思想及其诗歌创作的互动[532]

  • 弘一法师:最上乘的艺术,皆来自佛法[639]

  • 为什么在佛教的众多流派中,禅宗能一枝独秀?[720]

  • 从《坛经》看禅宗的智慧[972]

  • 赵朴初:佛教与中国文化完全打成一片,而无法分割了[687]

  • 禅宗最后立宗的法眼宗 它的教禅圆融观有何特点?[858]

  • 禅宗“打禅七”与净土宗“打佛七”的异同[1071]

  • 王阳明的思想与禅宗有什么关系[1166]

  • 六祖惠能大师诞辰纪念日:一花开五叶,结果自然成[1507]

  • 禅宗“不立文字”的因缘探析[709]

  • 网络热词“呵呵”竟是佛教用语![1089]

  •  
    设为首页 | 加入收藏 | 联系站长 | 友情链接 | 版权申明 | 管理登录 | 
    版权所有 Copyright© 2005 佛学研究        站长:wuys
    Powered by:Great Tang Hua Wei & XaWebs.com 2.0(2006)