home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / bit / listserv / ibmmain / 1828 < prev    next >
Encoding:
Text File  |  1992-07-29  |  3.0 KB  |  67 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!paladin.american.edu!auvm!STANFORD.BITNET!M.LAWRENCE
  3. Message-ID: <IBM-MAIN%92072914063839@RICEVM1.RICE.EDU>
  4. Newsgroups: bit.listserv.ibm-main
  5. Date:         Wed, 29 Jul 1992 12:04:58 PDT
  6. Sender:       IBM Mainframe Discussion list <IBM-MAIN@RICEVM1.BITNET>
  7. From:         "Mark C. Lawrence" <M.Lawrence@STANFORD.BITNET>
  8. Subject:      Re: UNIT and VOLUME specification (was: esoteric device message)
  9. Lines: 56
  10.  
  11. REPLY TO 07/29/92 11:10 FROM IBM-MAIN@RICEVM1.BITNET "IBM Mainframe Discussion
  12. list": Re: UNIT and VOLUME specification (was: esoteric device message)
  13.  
  14. >From:         Jerry Bryan <BRYAN@WVNVM.WVNET.EDU>
  15. >Subject:      Re: UNIT and VOLUME specification (was: esoteric device message)
  16. >
  17. >In article <IBM-MAIN%92072911491934@RICEVM1.RICE.EDU>, "Mark C. Lawrence"
  18. ><M.Lawrence@STANFORD.BITNET> says:
  19. >>Well, I think the simple answer is, "because MVS is too stupid to
  20. >>go look for the volume".  Obviously it wouldn't be real hard to do;
  21. >>just scan thru all the UCBs for online disks.  I wonder if this is on
  22. >>the list of SHARE requirements?
  23. >>
  24. >>This limitation goes all the way back to OS/360.  I think the logic
  25. >>used is:  (1) find a suitable UNIT, (2) find (or mount) a suitable
  26. >>VOLUME on that UNIT (or in that unit class).  At a time when most
  27. >>disks were mountable, this made a lot of sense.  In the era of
  28. >>nonremoveable disks it no longer does.
  29. >
  30. >I think the simple answer is not quite so simple.  The real reason
  31. >(at least historically under OS/360) is that ALTRES might be a tape.
  32. Well, yes, it could be a tape too.  My point was that the volume
  33. probably wasn't mounted, so the current algorithm made sense at the time.
  34.  
  35. >In fact, it is even more subtle that that.  ALTRES might be a
  36. >3330 or a 3350 or a 3380 or a 3390 or a 3420 tape or a 3480
  37. >tape or a (pick a unit type of your choice).  Some of these
  38. >possibilities are obviously nonsensical if ALTRES is already
  39. >mounted ...
  40.  
  41. They are all nonsensical if ALTRES is already mounted, especially if
  42. ALTRES is a non-removeable device, since, as you point out, duplicate
  43. volsers are not allowed.
  44.  
  45. >For example, vary ALTRES offline.  Should the JCL be parsed
  46. >any differently while ALTRES is offline?
  47.  
  48. Not exactly PARSED differently.  But unit resolution handled differently.
  49. I suggest the following algorithm for resolving UNIT for *existing*
  50. data sets (i.e. DISP=OLD or SHR) where no UNIT is known but a volume
  51. is specified:
  52.  
  53.          1.  Assume that the unit is a DASD device
  54.          2.  Scan the UCBs for a DASD unit that is online and has
  55.              the requested volser.
  56.          3.  If found, set UNIT to the unit type for the found vol.
  57.          4.  If not found, issue error message.
  58.  
  59. >If ALTRES were offline,
  60. >how on earth could you figure out what the proper device type was?
  61.  
  62. You couldn't.  But this is a fairly rare event, in my experience.
  63. At any rate, most references to existing data sets are made thru the
  64. catalog, which has the unit information.
  65.  
  66. To:  IBM-MAIN@RICEVM1.BITNET
  67.