home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / bit / listserv / ibmmain / 2700 < prev    next >
Encoding:
Text File  |  1992-11-23  |  4.2 KB  |  75 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%92112314093884@RICEVM1.RICE.EDU>
  4. Newsgroups: bit.listserv.ibm-main
  5. Date:         Mon, 23 Nov 1992 11:59:55 PST
  6. Sender:       IBM Mainframe Discussion list <IBM-MAIN@RICEVM1.BITNET>
  7. From:         "Mark C. Lawrence" <M.Lawrence@STANFORD.BITNET>
  8. Subject:      MVS Data Set Allocation and Disposition (was: IEFBR14)
  9. Comments: To: ibm-main@ricevm1.bitnet
  10. Lines: 63
  11.  
  12. REPLY TO 11/20/92 18:51 FROM IBM-MAIN@RICEVM1.BITNET "IBM Mainframe Discussion
  13. list": Re: IEFBR14
  14.  
  15. On Fri, 20 Nov 1992 Leonard D Woren <LDW@USCMVSA.BITNET> said,
  16. >ml> Now, suppose that you specified UNIT and VOL on the DD statement.  Since
  17. >ml> volume information is available, MOD is treated (for allocation/disposition
  18. >ml> purposes) like OLD.
  19. > ... now I think that MVS is just
  20. >broken.  I got interesting results from the tests.  In both batch and
  21. >TSO, with or without a SPACE specification, it cataloged the dataset
  22. >WITHOUT CREATING IT when MOD,CATLG was used for a non-existant dataset
  23. >and a specific volume was coded.
  24.  
  25. Please excuse the second posting, but I read this after my earlier post, and
  26. realized I hadn't addressed this issue.
  27.  
  28. The problem (a feature, not a bug!) has to do with the separation (in pre-SMS)
  29. of *allocation* and *disposition* services, reflected in the "status" and
  30. "disposition" subparameters of DISP.  The "status" (first subparm) indicates
  31. what the status of the file is expected to be *at step initiation*, and
  32. therefore what the initiator should do about it *at step initiation*.  At
  33. initiation, we need to allocate a unit (such as a disk volume or tape drive),
  34. possibly mount a volume on it, possibly allocate space for it.  If we said
  35. DISP=OLD (or MOD), and specified UNIT and VOL, the system has all the info
  36. needed to complete the allocation.  The JFCB is filled in, there is a valid
  37. UCB pointer, etc.  Now, if the file doesn't exist, OPEN will bomb because the
  38. OBTAIN will fail, and we'll get completion code 213-04.  But if we never open,
  39. no problem.  Initiation will fail if there is not sufficient information to do
  40. the allocation.  For an OLD data set, lack of UNIT/VOL information implies a
  41. search of the catalog and the pass queue.  If the file is not found in either,
  42. allocation must fail because there is no way to define the unit and volume,
  43. thus IEF212I DATA SET NOT FOUND.  If the unit information is available from
  44. the pass queue, catalog, or DD statement then allocation can be completed,
  45. even if the file does not exist.
  46.  
  47. The "disposition" subparameter (second subparm) indicates what action you want
  48. performed *at step termination*.  Cataloging is done at step termination.  So,
  49. lets look at what happens in disposition processing for various disposition
  50. values.  KEEP says "just leave it".  For tape, it implies rewind and unload,
  51. and appropriate message to operator.  For disk, no action is needed, so a file
  52. that exists continues to exist, and a file that doesn't exist continues to not
  53. exist.  CATLG says "keep it and catalog it" so in addition to the above action
  54. we must create a catalog entry.  So, we build a volume list from the
  55. information in the JFCB at step termination (possibly different than at step
  56. initiation), and issue a catalog SVC.  Now, for our nonexistant disk file
  57. (that had UNIT and VOL specified), we have all the info we need...a unit, a
  58. volume...so we can catalog it no problem.  Cataloging will fail if we don't
  59. have enough information to create the catalog entry (or if there is a
  60. duplicate entry), but whether the file actually exists is irrelevant.
  61.  
  62. Cataloging at step termination leads to a multitude of well-known problems,
  63. such as cataloging failing without causing step failure (IEF287I NOT CATALOGED
  64. 2).  It was probably done this way because in the general case one doesn't
  65. have a complete volume list until step termination, as the file may have been
  66. extended beyond its original volume during the step.  Also, it was not assumed
  67. that all (or even most) data sets would be cataloged.
  68.  
  69. Mark C. Lawrence
  70. Systems Programmer     Internet: M.Lawrence@Forsythe.Stanford.edu
  71. Stanford Data Center     Bitnet: M.Lawrence@STANFORD
  72. Stanford, CA 94305-4136     Tel: (415) 723-4976
  73.  
  74. To:  IBM-MAIN@RICEVM1.BITNET
  75.