Unit and volume affinity for non-system-managed data sets and Data Sets on a System-Managed Tape Volume

When two or more volumes are assigned the same device, the volumes are said to have unit affinity within the same job step allocation. Unit affinity implies deferred mounting for all except one of the volumes.

The following definitions apply to unit affinity:

A referencing DD is the DD that specifies the UNIT=AFF keyword.
A referenced DD is the DD pointed to by a referencing DD.
A primary DD is the first DD in a unit affinity chain.
A unit affinity chain is the set of DDs that share the same primary DD.

In the following example, DD2 is a referencing DD; DD1 is its referenced DD. DD3 is also a referencing DD; DD2 is its referenced DD. DD1 is the primary DD for the unit affinity chain that consists of the DD1, DD2, and DD3.

//ST1 EXEC
//DD1 DD DSN=A,DISP=(,CATLG),UNIT=3480
//DD2 DD DSN=B,DISP=(,CATLG),UNIT=AFF=DD1
//DD3 DD DSN=C,DISP=(,CATLG),UNIT=AFF=DD2

A related concept is volume affinity. When two or more data sets share one or more volumes, the data sets have volume affinity. See Stacking data sets for additional information on stacking data sets on one or more volumes.

Explicit unit affinity: To reduce the number of devices for a step, code UNIT=AFF to request that an existing data set be assigned to the same device(s) assigned for an earlier DD statement in the same step. Code:

//ddname DD  UNIT=AFF=ddname,...

Note: Do not specify UNIT=AFF for a NEW (or MOD treated as NEW) data set that references a non-SMS-managed DASD data set; the allocation will fail.

For concatenated data sets, code the following to assign the data sets to the same device:

   //DD1    DD  DSNAME=dataset1,...
   //       DD  DSNAME=dataset2,UNIT=AFF=DD1,...
   //       DD  DSNAME=dataset3,UNIT=AFF=DD1,...

When you use explicit unit affinity, it is recommended that you use UNIT=AFF to reference the previous DD in the unit affinity chain, rather than the primary DD. That is, code:

   //DD1    DD  DSNAME=dataset1,...
   //DD2    DD  DSNAME=dataset2,UNIT=AFF=DD1,...
   //DD3    DD  DSNAME=dataset3,UNIT=AFF=DD2,...
   //DD4    DD  DSNAME=dataset3,UNIT=AFF=DD3,...

rather than:

   //DD1    DD  DSNAME=dataset1,...
   //DD2    DD  DSNAME=dataset2,UNIT=AFF=DD1,...
   //DD3    DD  DSNAME=dataset3,UNIT=AFF=DD1,...
   //DD4    DD  DSNAME=dataset3,UNIT=AFF=DD1,...

Always referencing the previous DD means that, if any condition causes the system to ignore unit affinity for one of the DDs in the chain, any subsequent DDs in the chain will still be allocated to a single unit, rather than to different units.

Implied unit affinity: Implied unit affinity exists among the volumes for one data set when the DD statement requests more volumes than devices.

Attention: If all of the following conditions are present, the data set on the referencing DD statement, which requests unit affinity, is written over by the data set on the referenced DD statement:

The referenced DD statement makes a nonspecific volume request.
The data set on the referencing DD statement is opened before the referenced data set.
The tape is not unloaded before the referenced data set is opened and the LABEL parameter does not request positioning of the tape to check tape labels. A tape device allocated to more than one data set is not unloaded when it is dynamically unallocated, or when it is closed and FREE=CLOSE is specified.

Unit affinity processing for Data Sets on a System-Managed Tape Volume: Table 1 contains examples that apply unit-affinity principles to data sets requested on system-managed tape volumes. The system verifies that the primary (referenced) DD statement has a device pool that is a proper subset of the secondary (referencing) DD statement. Therefore, the system honors unit-affinity requests only when each device type to which the primary DD statement is eligible is also contained in the device pool of the secondary DD statement.

The column headings have the following meanings:

Request: Indicates either primary (referenced) DD statement or secondary (referencing) DD statement.
Library Eligibility: Indicates the libraries to which the DD statement is eligible.
Device Type Eligibility: Indicates the device types to which the DD statement is eligible.
Action Taken: Whether the affinity request is honored or ignored. If the request is honored, whether the library or device type eligibility is reduced.
Final Eligibility: The resulting library or device type eligibility used to allocate devices.

Table 1. Unit-Affinity Examples of Tape Library Requests
Requestor	Library eligibility	Device type eligibility	Action taken	Final eligibility
Libraries and device pools of requestors are identical
Primary	LIB1	3490	Honor	LIB1, 3490
Secondary	LIB1	3490	Honor
*Libraries of primary requestor are proper subset of secondary*
Primary	LIB1	3490	Honor and Reduce	LIB1, 3490
Secondary	LIB1, LIB2	3490	Honor and Reduce
*Device pool of primary requestor is proper subset of secondary*
Primary	LIB1	3490	Honor and Reduce	LIB1 and 3490
Secondary	LIB1	3490, 3480X	Honor and Reduce
*Libraries of primary requestor are completely different from secondary*
Primary	LIB1	3490	Ignore	LIB1, 3490
Secondary	LIB2	3490	Ignore	LIB2, 3490
*Device pool of primary requestor is completely different from secondary*
Primary	LIB1	3490	Ignore	LIB1, 3490
Secondary	LIB1	3480X	Ignore	LIB1, 3480X
*Libraries of primary requestor are not proper subset of secondary*
Primary	LIB1, LIB2	3490	Ignore	LIB1, LIB2, 3490
Secondary	LIB1	3490	Ignore	LIB1, 3490
*Device pool of primary requestor is not proper subset of secondary*
Primary	LIB1	3490, 3480X	Ignore	LIB1, 3490, 3480X
Secondary	LIB1	3480X	Ignore	LIB1, 3480X
*Device pools identical; both are non-library requestors*
Primary	Non-library request	3490	Honor	3490
Secondary	Non-library request	3490	Honor
*Device pool of primary requestor is proper subset of secondary; both are non-library requestors*
Primary	Non-library request	3490	Honor and Reduce	3490
Secondary	Non-library request	3490, 3480X	Honor and Reduce
*Device pool of primary requestor is not proper subset of secondary; both are non-library requestors*
Primary	Non-library request	3490, 3480X	Ignore	3490, 3480X
Secondary	Non-library request	3490	Ignore	3490
*Primary is library requestor but secondary is non-library requestor*
Primary	LIB1	3490	Ignore	LIB1, 3490
Secondary	Non-library request	3490	Ignore	3490

Note: 3480X is the device type for the 3490 model tape drives and 3490 is the device type for the 3490E model tape drives.

Device eligibility: Non-system-managed data sets are eligible to a device when they can be allocated to that device type. The data sets on a system-managed tape volume are eligible to a device when they can be allocated to that device type, and when both the volume and the device reside in the same system-managed tape library. The catalog contains information about the types of devices to which a data set is eligible only if the data set is cataloged.

For the system to honor a request for unit affinity, the referenced DD must be eligible to the same devices as the referencing DD statement. In addition, the devices to which the referenced DD statement is eligible must either be a subset of, or the same as, the devices to which the referencing DD is eligible. In all other cases, the system ignores unit affinity, but the allocation will succeed.

These rules are illustrated by the following example, in which:

TAPEX is eligible to a 3480X or a 3480.
DS3480 is cataloged as eligible to a 3480. The unit name 3480 has two generic names associated with it: 3480 and 3480X.
DS3480X is cataloged as eligible to a 3480X.
DS3480X2 is cataloged as eligible to a 3480X.

//DD1 DD UNIT=TAPEX
//DD2 DD DSN=DS3480,UNIT=AFF=DD1
//DD3 DD DSN=DS3480X,UNIT=AFF=DD2
//DD4 DD DSN=DS3480X2,UNIT=AFF=DD1

If you do not request volume affinity, or the request for volume affinity does not break the unit affinity (see Interaction of unit and volume affinity requests), the following unit affinities will result:

DD1 and DD2 can have unit affinity, because DD1 and DD2 are both eligible to a 3480 and a 3480X.
DD4 can have unit affinity to DD3, because DD3 and DD4 are both eligible to a 3480X.
Neither DD3 nor DD4 can have unit affinity to DD1, because neither is eligible to a 3480. Thus, the system ignores unit affinity for DD3 or DD4; DD3 and DD4 are not eligible for the same devices as DD1.

Exception to Device Eligibility

The system will not honor unit affinity when all of the following conditions are met:

The referenced DD is eligible to a 3480X device
The referencing DD is eligible to both a 3480 and a 3480X device
The system was initialized to attempt to allocate a 3480 before a 3480X.

The exception is illustrated by the following example, in which:

The system has been initialized to attempt to allocate a 3480 device before allocating a 3480X device.
DS3480 is cataloged as eligible to a 3480. The unit name 3480 has two generic names associated with it: 3480 and 3480X.

//DD1 DD UNIT=3480X
//DD2 DD DSN=DS3480,UNIT=AFF=DD1

In this example, the system does not honor the request for unit affinity; each DD statement is allocated to a separate device.