Newsgroups: bit.listserv.ibm-main
Date:         Mon, 23 Nov 1992 11:59:55 PST
From:         "Mark C. Lawrence" <M.Lawrence@STANFORD.BITNET>
Subject:      MVS Data Set Allocation and Disposition (was: IEFBR14)
Comments: To: ibm-main@ricevm1.bitnet

REPLY TO 11/20/92 18:51 FROM IBM-MAIN@RICEVM1.BITNET "IBM Mainframe Discussion
list": Re: IEFBR14

On Fri, 20 Nov 1992 Leonard D Woren <LDW@USCMVSA.BITNET> said,
>ml> Now, suppose that you specified UNIT and VOL on the DD statement.  Since
>ml> volume information is available, MOD is treated (for allocation/disposition
>ml> purposes) like OLD.
> ... now I think that MVS is just
>broken.  I got interesting results from the tests.  In both batch and
>TSO, with or without a SPACE specification, it cataloged the dataset
>WITHOUT CREATING IT when MOD,CATLG was used for a non-existant dataset
>and a specific volume was coded.

Please excuse the second posting, but I read this after my earlier post, and
realized I hadn't addressed this issue.

The problem (a feature, not a bug!) has to do with the separation (in pre-SMS)
of *allocation* and *disposition* services, reflected in the "status" and
"disposition" subparameters of DISP.  The "status" (first subparm) indicates
what the status of the file is expected to be *at step initiation*, and
therefore what the initiator should do about it *at step initiation*.  At
initiation, we need to allocate a unit (such as a disk volume or tape drive),
possibly mount a volume on it, possibly allocate space for it.  If we said
DISP=OLD (or MOD), and specified UNIT and VOL, the system has all the info
needed to complete the allocation.  The JFCB is filled in, there is a valid
UCB pointer, etc.  Now, if the file doesn't exist, OPEN will bomb because the
OBTAIN will fail, and we'll get completion code 213-04.  But if we never open,
no problem.  Initiation will fail if there is not sufficient information to do
the allocation.  For an OLD data set, lack of UNIT/VOL information implies a
search of the catalog and the pass queue.  If the file is not found in either,
allocation must fail because there is no way to define the unit and volume,
thus IEF212I DATA SET NOT FOUND.  If the unit information is available from
the pass queue, catalog, or DD statement then allocation can be completed,
even if the file does not exist.

The "disposition" subparameter (second subparm) indicates what action you want
performed *at step termination*.  Cataloging is done at step termination.  So,
lets look at what happens in disposition processing for various disposition
values.  KEEP says "just leave it".  For tape, it implies rewind and unload,
and appropriate message to operator.  For disk, no action is needed, so a file
that exists continues to exist, and a file that doesn't exist continues to not
exist.  CATLG says "keep it and catalog it" so in addition to the above action
we must create a catalog entry.  So, we build a volume list from the
information in the JFCB at step termination (possibly different than at step
initiation), and issue a catalog SVC.  Now, for our nonexistant disk file
(that had UNIT and VOL specified), we have all the info we need...a unit, a
volume...so we can catalog it no problem.  Cataloging will fail if we don't
have enough information to create the catalog entry (or if there is a
duplicate entry), but whether the file actually exists is irrelevant.

Cataloging at step termination leads to a multitude of well-known problems,
such as cataloging failing without causing step failure (IEF287I NOT CATALOGED
2).  It was probably done this way because in the general case one doesn't
have a complete volume list until step termination, as the file may have been
extended beyond its original volume during the step.  Also, it was not assumed
that all (or even most) data sets would be cataloged.

Mark C. Lawrence
Systems Programmer     Internet: M.Lawrence@Forsythe.Stanford.edu
Stanford Data Center     Bitnet: M.Lawrence@STANFORD
Stanford, CA 94305-4136     Tel: (415) 723-4976

To:  IBM-MAIN@RICEVM1.BITNET