SPACPRIM—reduce primary space allocation (used with StopX37/II)
SPACPRIM stops Space-Not-Available conditions during step initialization.
Space-Not-Available conditions arise when z/OS is unable to satisfy space allocation for a new data set.
SPACPRIM interacts with modules in the z/OS allocation function. When a user or job is requesting allocation of a new data set, the primary space request must be satisfied in no more than five extents. If the space is unavailable on the requested volume, SPACPRIM can reduce the primary space request in user-specified increments and retry the allocation. This feature allows an initiator to start a job that would normally be failed due to lack of space.
A smaller primary allocation for the data set can still allow successful processing because
- The primary space in the JCL might be set at the maximum necessary space for conditions that occur only infrequently
- The data set has secondary allocations to handle expansion
SPACPRIM prevents Space-Not-Available conditions for:
- All types of non-VSAM data sets, including PDSEs
- SMS-managed VSAM data sets that are allocated in JCL
- IDCAMS-defined VSAM data sets
SPACPRIM reduces the primary allocation down to a specified limit. The limit can be selectively applied to resources based on data set name; job name; data or storage class; data set size or maximum possible size; and so on.
The following job is an example of the SPACPRIM recovery attempts:
//STEP1 EXEC PGM=IEFBR14
//DD1 DD DSN=&&TEMP,DISP=(NEW,CATLG),
//DD2 DD DSN=EXAMPLE.DATASET2,DISP=(NEW,CATLG),
// UNIT=SYSDA,SPACE=(CYL,(9999,10))
//DD3 DD DSN=EXAMPLE.DATASET1,DISP=(NEW,CATLG),
//UNIT=SYSDA,SPACE=(CYL,(9999,10)),VOL=SER=TEMP99
//
In the preceding example, recovery would first be attempted on DD3, followed by DD2, and then DD1. If recovery failed on DD1, messages concerning successful recovery for DD3 and DD2 would precede the failure message for DD1.
For more information, see: