Checking for conflicts with your existing allocation environment

When you invoke the DYNALLOC macro to perform dsname dynamic allocation, an “allocation environment” already exists for your request. It consists of the allocation requests made through your JCL or earlier dynamic allocations, that have not yet been deallocated. The system considers these resources to be existing allocations, and goes to them first to fill your dynamic allocation requests.

Dynamic allocation cannot satisfy a dsname allocation request that is in conflict with your existing allocation environment. Environmental conflicts can cause your request to fail when your dsname allocation request specifies:

A ddname that is associated with an existing allocation that is in use.
A ddname that is associated with a group of concatenated data sets defined as permanently concatenated. (For a definition of permanently concatenated, see Requesting the permanently concatenated attribute.)
A ddname that is associated with an existing allocation that does not have the convertible attribute or that does not fulfill the conditions listed under Using an existing allocation to fulfill a dsname allocation request.
A new non-temporary data set with the same dsname as that of an existing allocation.
This is not a conflict if the request specifies a different volume serial number. Non-temporary data sets can have the same dsname if they do not reside on the same volume.
An existing data set (by specifying a disposition of OLD or SHR) that is not permanently allocated, not in-use, and has a disposition of DELETE. A data set with these characteristics might be deleted before your program requests it.
This is not a conflict if your request specifies a different volume serial number, and the allocation on the specified volume is permanently allocated and does not have a disposition of DELETE.

MVS™ might allocate a different data set than you intend when you have multiple versions of the same data set, with the same data set name, residing on different volumes. When a data set with the same name as the intended data set has been previously allocated (perhaps using an alias name) but not freed, then the current allocate request might not allocate the intended version.

Avoid allocation of the incorrect data set in the following ways:

Specify the volume and unit where the data set to be allocated resides by using the DALVSER and DALUNIT text units in the dynamic allocation parameter list. See Dsname allocation text units for more information.
If the data set to be allocated is not cataloged in the master catalog, and a data set with the same name is cataloged in the master catalog, then you must specify DALVSER and DALUNIT.
Free existing allocations for the same data set name (or alias names) using dynamic unallocation.
Use a unique data set name.
Set the no-conversion flag in the dynamic allocation block (S99NOCNV in S99FLAG1) to prevent the use of existing allocations for the same data set name. See Setting up the request block for more information. An alternate method is to code the IEFDB401 installation exit to set the S99NOCNV flag. See z/OS MVS Installation Exits for more information.