home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / bit / listserv / ibmmain / 1830 < prev    next >
Encoding:
Text File  |  1992-07-29  |  4.3 KB  |  84 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%92072923410645@RICEVM1.RICE.EDU>
  4. Newsgroups: bit.listserv.ibm-main
  5. Date:         Wed, 29 Jul 1992 21:37: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: 73
  10.  
  11. On Wed, 29 Jul 1992 12:25:37 EDT, BENSON@POKVMCR3.VNET.IBM.COM said:
  12. > Leonard, in answer to you comments - (a) SMS is our strategic
  13. > direction and our desire is that everyone use it, (b) I can't
  14. > speak for the future but that is certainly true today, (c) no.
  15.  
  16. Then you have to fix it so that sysres can be SMS managed.  This means
  17. replacing the SYS% conversion silliness with something that can
  18. actually be used.  How many shops have *every* dataset on sysres named
  19. SYS1.something???  Until CBIPO ships the system that way, *I* never
  20. will.  And I don't think you want to limit things that way anyway.
  21. A more general solution is needed.  I'd suggest some prefixing method
  22. to specify the volser.  This limits the dsnames to less than the full
  23. 44 characters, but this shouldn't be a problem for sysres datasets.
  24. For example, let me define an index level, say, altres, such that any
  25. reference to altres.SYS1.LINKLIB means SYS1.LINKLIB on ALTRES.
  26. (Actually, what would be really nice would be the ability to specify
  27. any volser via syntax like "ALTRES:SYS1.LINKLIB".  I won't hold my
  28. breath...)
  29.  
  30. Until sysres can be cleanly SMS managed, and until *all* other IBM
  31. utilities can work with SMS volumes, IBM cannot reasonably state that
  32. SMS is the strategic direction.  IBM finally fixed the problem of
  33. IDCAMS BUILDIX requiring its internally-created IDC work files to be
  34. on non-SMS by answering an old unrelated SHARE requirement -- allow
  35. external sort to be used.  This was actually a good solution for that
  36. particular case.  But IBM's answer to complaints that IEHMOVE doesn't
  37. work on SMS volumes of "IEHMOVE is obsolete, use IEBCOPY and DFDSS" is
  38. inappropriate for one glaring reason -- users will have IEHMOVE-
  39. unloaded datasets for a long time, and they need to be able to reload
  40. them.  IEHMOVE could be fixed rather easily -- THROW AWAY the silly
  41. code that does the manipulation of its work datasets via SVC 32, and
  42. either allocate them with SVC 99, or (best) allow them to be specified
  43. in the JCL.  Also, change the creation of the output dataset from SVC
  44. 32 to SVC 99.  If these reasonably simple changes were made, many
  45. advantages would result.  IEHMOVE could run without APF authorization.
  46. Performance would be improved, since VIO work files could be used.
  47. And unloaded datasets from obsolete device types could be reloaded to
  48. VIO and then converted over to current dasd.  Have I submitted a SHARE
  49. requirement?  No.  Why bother, when IBM has made it clear that they
  50. don't understand, and have no intention of fixing IEHMOVE?  If you can
  51. assure me that the requirement will be accepted when submitted, and
  52. targetted for near-term delivery, then I'll submit it.  Otherwise, why
  53. should I waste my time?
  54.  
  55.  
  56. On Wed, 29 Jul 1992 13:32:08 EDT,
  57.    Jerry Bryan <BRYAN@WVNVM.WVNET.EDU> said:
  58. > >Specifically, if ALTRES (for example) is permanently resident, why
  59. > >do the following fail without UNIT=nnnn?
  60.  
  61. > (...)
  62. > I think the simple answer is not quite so simple.  The real reason
  63. > (at least historically under OS/360) is that ALTRES might be a tape.
  64.  
  65. Irrelevant.  Note that I specifically was referring to PERMANENTLY
  66. RESIDENT disks.
  67.  
  68. > For example, vary ALTRES offline.  Should the JCL be parsed
  69. > any differently while ALTRES is offline?  If ALTRES were offline,
  70. > how on earth could you figure out what the proper device type was?
  71.  
  72. Well, someone else already commented on the JCL parsing issue.  I
  73. assume you just meant "should it mean something different if ALTRES is
  74. offline?"  Yes!  It's quite simple.  VOL=SER= without a UNIT= should
  75. work only for permanently resident dasd.  If you reference a
  76. non-mounted disk volume without UNIT=, the job should fail just as it
  77. does now if you omit the UNIT=.  All I'm asking for is that UNIT=
  78. should be implicitly assigned by MVS if the VOL=SER= refers to a
  79. permanently resident dasd.  Quite simple, if the designers had any
  80. imagination.  In fact, this is so simple that a JES2 internal text
  81. exit could be easily written to do exactly that!  Hmmm...
  82.  
  83. /Leonard
  84.