home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / bit / listserv / ibmmain / 1761 < prev    next >
Encoding:
Text File  |  1992-07-21  |  5.3 KB  |  115 lines

  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!uwm.edu!psuvax1!psuvm!auvm!NYUCCVM.BITNET!URARC
  3. Organization: New York University - University Computer Center
  4. X-Acknowledge-To: <URARC@NYUCCVM.BITNET>
  5. Message-ID: <IBM-MAIN%92072118203411@RICEVM1.RICE.EDU>
  6. Newsgroups: bit.listserv.ibm-main
  7. Date:         Tue, 21 Jul 1992 18:52:32 GMT
  8. Sender:       IBM Mainframe Discussion list <IBM-MAIN@RICEVM1.BITNET>
  9. From:         "Alina R. Chu" <URARC@NYUCCVM.BITNET>
  10. Subject: Re: Wylbur
  11. In-Reply-To:  Message of Thu, 16 Jul 1992 00:15:00 PDT from <LDW@USCMVSA>
  12. Lines: 101
  13.  
  14. On Thu, 16 Jul 1992 00:15:00 PDT Leonard D Woren said:
  15. >On Wed, 15 Jul 1992 11:22:00 EST,
  16. >   "Rostyslaw J. Lewyckyj" <URJLEW@UNC.BITNET> said:
  17. >> Leonard
  18. >> I am replying to the list, rather than to you indivdually,
  19. >> because perhaps I can get some usefull feedback in spite
  20. >> of the gasoline and lighted match of your "a corpse is a
  21. >> corpse" posting.
  22. >
  23. >Credit where credit is due.  I got that line from someone at Stanford
  24. >University Hospital (who will remain nameless here, but he's probably
  25. >laughing his head off at what's going on here), who was more than
  26. >happy to get TSO running so he wouldn't have to use Wylbur.
  27. >
  28. >> One of the things people seem to like about WYLBUR is its
  29. >> editor.
  30. >
  31. >Wylbur has something besides an editor?
  32. >
  33. >> ... Instead I solicit any pointers to a WYLBUR editor to ISPF editor
  34. >> conversion manual, MACRO library, etc.
  35. >
  36. >It's been 15 years since I used Wylbur for more than a minute at a
  37. >time, and it's been 12 years since I've seen Wylbur.  I don't miss it.
  38. >This is a long way of saying that I personally don't know of any such
  39. >conversion aids.
  40. >
  41. >> The second requirement is for a WYLBUR EXEC to CLIST or REXX
  42. >> EXEC converter.
  43. >
  44. >I suspect that such a beast would be painful to write, since the
  45. >editor commands are so different between Wylbur and ISPF.
  46. >
  47. >> Another is for something to take the place of ACTIVE files for
  48. >> saving the file currently being edited in case of a disconnect,
  49. >
  50. >Finally something I can answer.  The ISPF edit command "RECOVERY ON"
  51. >will create backup datasets to accomplish exactly what you want.
  52. >In ISPF/PDF V3, they also support the edit UNDO command.  Does Wylbur
  53. >have that?
  54. >
  55. >> and QUICK? files.
  56. >
  57. >I don't know what that is.
  58. >
  59. >
  60. >As with any change, and as I think someone else touched on, some
  61. >people will be interested in learning the new stuff quickly, and
  62. >others will bitch and moan, need to be dragged kicking and screaming
  63. >into newer stuff, and then want to be spoon fed.  ISPF has very
  64. >comprehensive online help.  The editor is such that you can know only
  65. >a small amount about it and get your editing done.  You can learn more
  66. >and more capabilities as you go, and they're easy to find in the
  67. >online help.  When I learned ISPF and ISPF edit, I had nobody to teach
  68. >me.  I read the tutorial and the online help.
  69. >
  70. >> P.S. Oh, oh I forgot one big requirement. $$$$ for more hardware.
  71. >
  72. >This is partially a straw man.  The reason that utilization goes up is
  73. >that ISPF allows people to get their work done faster, so they run
  74. >more jobs and do more interactive processing.  (Can you split screen
  75. >in Wylbur and view your output while editing your source program?)
  76. >(In 1977, I said that Wylbur might be reasonable when it got some
  77. >trivial functions like the ability to rename a dataset without having
  78. >to submit a batch job.  It was many years before I heard of this being
  79. >added to Wylbur.)  Since people costs are high and rising, and
  80. >hardware costs are decreasing, it makes sense to me to invest a bit
  81. >more in hardware to save more in other areas.  If you can have your
  82. >application programmers get their work done faster, either you don't
  83. >have to expand the staff as fast, or the users get their applications
  84. >faster, resulting in happier users.
  85. >
  86. >
  87. >/Leonard
  88.  
  89. Leonard,
  90.    There are quite a few things that have changed with WYLBUR since you
  91. used it.
  92.    We use OBS/WYLBUR currently and use TSO/ISPF for specific applications
  93. which require it.  WYLBUR is still our primary editting and job submission
  94. environment.  With WYLBUR like TSO/ISPF you can split your screen and look
  95. at your source and your output at the same time.  In addition, the qwik file
  96. facility allows you to have multiple "active" areas that you can bounce
  97. between.  These are saved for you automatically if the system crashes like
  98. the ACTIVE file.  They allow you to work on multiple programs simultaneously
  99. and check the results of your batch jobs.  I like to have multiple copies of
  100. the same program with different changes and test each one.  I save these files
  101. less frequently than I would with one active area.  Each of these qwik files
  102. fill your screen which I prefer to trying to split multiple times in ISPF.
  103. The editor is full screen with ISPF-like line commands as well.
  104.   The flexibility of the "change" command, the ability to submit a batch
  105. job from a file or library member without editting it, the online help, the
  106. tutorial (LEARN), and finally the ability to efficiently share resources
  107. among hundreds of users.
  108.   I like TSO/ISPF for some things but for editting and job submission I prefer
  109. WYLBUR.  TSO/ISPF has quite alot of flexibility as well and I have seen
  110. some people very experienced with the bells and whistles do some neat editting
  111. tricks.  I feel they both have their merits and should be used effectively
  112. together.
  113.  
  114.             ALINA    (URARC@NYUCCVM)
  115.