home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / bit / listserv / ibmmain / 1843 < prev    next >
Encoding:
Text File  |  1992-07-30  |  2.2 KB  |  54 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!paladin.american.edu!auvm!USCMVSA.BITNET!LDW
  3. Message-ID: <IBM-MAIN%92073018005951@RICEVM1.RICE.EDU>
  4. Newsgroups: bit.listserv.ibm-main
  5. Date:         Thu, 30 Jul 1992 15:58:00 PDT
  6. Sender:       IBM Mainframe Discussion list <IBM-MAIN@RICEVM1.BITNET>
  7. From:         Leonard D Woren <LDW@USCMVSA.BITNET>
  8. Subject:      Re: UNIT and VOLUME specification
  9. Lines: 43
  10.  
  11. > So, I need to scan the UCBs for each of up to 255 volumes that can be
  12. > specified on a single DD and if any are offline or not permres dasd
  13. > then the request fails.
  14.  
  15. Yes.  Why not?  The list of volsers can be built first, and then the
  16. ucb scan done once.
  17.  
  18. > Should I also assume/verify that all 255 are
  19. > mounted on the same device type?
  20.  
  21. No, why would you need to.  But I don't think what I'm asking for is
  22. very important in the multi-volume case, so it may not matter if it
  23. only worked for single volume datasets.
  24.  
  25. > Should I only allow old datasets to be allocated this way?
  26.  
  27. No.  Old datasets are usually referenced via the catalog.  The bigger
  28. benefit from this comes from handling new datasets.
  29.  
  30. > It sounds simple enough but I'm sure, if you've seen the code, you
  31. > know this is real spaghetti.
  32.  
  33. Ah hah.  So the real reason we don't get more user-friendly systems
  34. from IBM is that it's too hard to change the existing ancient cruddy
  35. code.  Well, I guess over the next 10 years this problem will solve
  36. itself, as everybody moves to *ix systems.
  37.  
  38. > While it would be nice to rewrite it
  39. > I can't see that happening because of all the dependencies that have
  40. > been built up over the years on the quirks and holes within our
  41. > processing.  We rewrote the converter a couple years ago and closed
  42. > all those holes and ended up with some pretty irate customers who
  43. > had JCL they hadn't touched in years all of the sudden stop working
  44. > because they had taken advantage of some hole.
  45.  
  46. I don't have sympathy for those customers.  If the manual says that
  47. something has to be done a certain way, and you do it in violation of
  48. the published doc, and it eventually stops working, you have no right
  49. to complain to the vendor.  But I can't imagine how the particular
  50. change that I'm suggesting could break any currently functioning JCL.
  51.  
  52.  
  53. /Leonard
  54.