Statements and parameters for ALLOCxx

2DGT_EXPDT
Identifies the action to be taken if a new data set allocation request specifies a two-digit year (yyddd) Expiration Date. Use one of the following options:
  • EXPDT (Batch JCL two-digit year Expiration Date Keyword)
  • DALEXPDT (Dynamic Allocation Expiration Date specification short form)

A two-digit year is always treated as 19yy (yyddd).

Dates of 00000, 98000, 99000, 99365, and 99366 are allowed regardless of the Policy in force.

POLICY(ALLOW)
Allow the data set allocation with no Expiration Date related message.
POLICY(FAIL)
Fail the data set allocation and issue a failure message. If a 2-digit year is specified on a JCL DD statement (EXPDT), failure message IEF429I is written to both the System Message and JCL Message portions of the job log. If the 2-digit year is specified on a Dynamic data set allocation (DALEXPDT), failure message IEF406I is written to the operator and Dynamic Allocation Error Return Code '000C'x with Class 3 Reason Code '03B8'x is returned to the SVC 99 caller.
POLICY(WARN)
Allow the data set allocation but issue a warning message. If a 2-digit year is specified on a JCL DD statement (EXPDT), warning message IEF428I is written to both the System Message and JCL Message portions of the job log. If the 2-digit year is specified on a Dynamic data set allocation (DALEXPDT), warning message IEF405I is written to the operator and Dynamic code '0054'x is returned to the SVC 99 caller.
Default: POLICY(ALLOW).
ALLC_OFFLN
Specifies the installation policy to be followed when an allocation request needs a device that is offline, or must wait for a non-specific volume or unit.

If all eligible devices are offline, they cannot be brought online without operator intervention. In this case, the system ignores the WAITHOLD and WAITNOH options and issues the WTOR immediately.

MAXNWAIT(nnn)
Specifies the number of WAITNOH decisions that are allowed to be made for the allocation request before the default specified on the POLICYNW parameter takes effect. The WAITNOH decisions counted are those that are specified either through the default on the POLICY parameter or through an installation exit in the EXITxx parmlib member. WAITNOH decisions made by the operator are not included in the MAXNWAIT count.
Value range: 1 - 255
Default: 5
POLICY ([WTOR|WAITHOLD|WAITNOH|CANCEL])
Specifies the default action to take. An installation exit can override the policy.
CANCEL
The installation policy is to cancel the allocation request. If a TSO/E user issued the allocation request, the user receives an error message. If a batch job or started task issued the request, the system cancels the job or task, releases its resources, and issues message IEF251I.
WAITHOLD
The installation policy is for the system to not release any of the devices that have already been allocated to this job before it waits for the required units or volumes. The system issues message IEF289E.

Using the WAITHOLD policy might cause a deadlock situation, particularly when the device is being used by a job that is going to wait. The system does not release any non-sharable devices (that is, non-DASD) that have already been allocated to the job before it waits for required units and volumes. To avoid this problem, do not specify WAITHOLD.

When devices for a job are held during a wait, and a device that was eligible for allocation to the job becomes ineligible for allocation (because of its use by a system utility, for example), the job might fail because it does not have enough devices to complete successfully. Message IEF700I in the job log identifies this failure. See message IEF700I for information about how to respond to this failure.

WAITNOH
The installation policy is to let the job wait while not holding the obtained resources. The system releases those devices that were allocated to this job, but that cannot be shared with other jobs. The system issues message IEF289E.
For an example of the WAITHOLD versus WAITNOH options, consider that JOBA owns an automatically switchable device and is waiting for a printer. JOBB owns the printer JOBA needs and is waiting for the automatically switchable device JOBA owns.
  • If the reply is WAITHOLD for each job, the two jobs wait until one job is canceled. This deadlock can be even more complex depending on the number of jobs that are waiting.
  • If the reply is WAITNOH for each job, allocation responds on a first-come, first-served basis. After the first job finishes using a resource, it is available to the second.
WTOR
The installation policy is to issue the message and let the operator decide about the needed device. The system displays one or more of the following messages on the operator's console:
  • IEF157E - <jobname> needs <nnn> units. All eligible units are currently allocated.
  • IEF238D - Reply [device name] [,] [‘wait’] or ‘cancel’
  • IEF244I - Unable to allocate <nnn> units. At least <nnn> allocated or offline units are needed.
  • IEF433D - Wait requested. Reply hold or nohold.
In addition, the system issues one or more of the following messages in response to invalid replies to the preceding messages:
  • IEF434D - Invalid reply (to message IEF433D). Reply hold or nohold.
  • IEF490I - Invalid reply (to message IEF238D) for one of the following reasons:
    • Device is not accessible.
    • Required system managed volume is not available.
    • Required volume is not available.
    • Replied device is not eligible.
    • Device could not be found in the configuration.
    • Device found in an offline library.
Default: WTOR
POLICYNW(CANCEL|WTOR)
Specifies how the system should handle the allocation request under the following circumstances:
  • Either WAITHOLD or WAITNOH is specified on the POLICY parameter and the system does not allow the job to wait for the needed device.
  • The maximum number of WAITNOH decisions (specified on the MAXNWAIT parameter) has been exceeded.

The system is to either cancel the allocation request (CANCEL) or issue a WTOR. When WTOR is selected, the system issues the messages listed earlier under WTOR. When CANCEL is selected, the system cancels the allocation request depending on how the request was issued. If a TSO/E user issued the allocation request, the user receives an error message. If a batch job or started task issued the request, the system cancels the job or task, releases its resources, and issues message IEF251I.

Default: WTOR
CATLG_ERR
Specifies the installation policy for handling certain types of errors that might occur when the system processes the disposition of batch unallocated data sets (data sets that have been unallocated at step termination time). The CATLG_ERR statement applies when the system is unable to:
  • Catalog a new data set for which the user specified a disposition of CATLG.
  • Catalog an old uncataloged data set for which the user specified a disposition of CATLG.
  • Recatalog an old cataloged data set for which the volume list was extended, and for which the user specified a disposition of CATLG, KEEP or PASS.
  • Roll an SMS-managed generation data set into the GDG base.
The CATLG_ERR statement does not apply when the user unallocates a data set before step termination through the following methods:
  • Dynamic deallocation (DYNALLOC macro)
  • Having previously specified FREE=CLOSE on the allocation request (DYNALLOC macro or DD statement in the job's JCL).
  • CATLG, UNCATLG, KEEP, PASS, or DELETE a new or old SMS-managed data set, including when the SMS subsystem is not available.
  • CATLG, UNCATLG, KEEP, PASS, or DELETE a new or old VSAM data set, including when the SMS subsystem is not available.
The CATLG_ERR statement does not apply when the user unallocates a data set before step termination through the following methods:
  • Dynamic deallocation (DYNALLOC macro).
  • Having previously specified FREE=CLOSE on the allocation request (DYNALLOC macro or DD statement in the job's JCL).
ERRORMSG(YES|NO)
Specifies whether the system is to issue an error message to the operator if one of the preceding errors occurs. When you specify ERRORMSG=YES, the system issues message IEF377I only if no other error messages were issued. If FAILJOB(YES) is also specified, the system terminates the job, releases its resources, and issues message IEF378I.
Default: NO
FAILJOB(YES|NO)
Specifies whether the system is to terminate the job if one of the preceding errors occurs. When a job is terminated by FAILJOB(YES), the termination is considered a post-execution error. Post-execution errors, which include but are not limited to FAILJOB(YES) terminations, are indicated by a 1 in the SMF30SYE bit in the SMF30STI field of the SMF30 subtype4 record.
Notes:
  1. The setting of the condition code is not affected.
  2. The job is not abnormally ended, unless the step that encountered the error had itself previously abnormally ended. Terminated means that subsequent steps are not taken.
  3. The normal disposition for data sets is taken, unless the step that encountered the error had already abnormally ended, in which case the abnormal or conditional disposition is taken.
Default: NO
SDSN_WAIT
Specifies the installation policy for batch jobs that must wait to enqueue on special types of data set names.
WAITALLOC([NO|YES])
Specifies whether to cancel jobs that must wait to enqueue on the following types of data set names:
  • GDG absolute generation data set name (unless the absolute generation data set name is specified on the JCL). See z/OS MVS JCL Reference for a discussion of how the system generates absolute generation names and how the system enqueues on absolute generation names when a relative generation name is specified.
  • Real data set name (when its corresponding alias data set name is specified on the JCL).
NO
The system cancels the job, releases its resources, and issues message IEF211I.
YES
When YES is specified, and a batch job's enqueue request cannot be satisfied, the system issues messages IEF861I, IEF863I, and IEF458D. The job waits, holding any resources that it might have acquired. The system operator can choose to cancel the job in response to message IEF458D, or allow the job to continue waiting until the enqueue becomes available. If the operator cancels the job, the system writes an informational message (IEF330I) to the job log.

Use caution when specifying YES. Allowing jobs to wait for data set availability can cause deadlocks with other jobs in the system.

When you specify YES, the system does not allow the job to wait for a data set when both of the following conditions are true:
  1. This job plus one (or more) other jobs have the data set allocated as DISP=SHR.
  2. This job requests that its use of the data set be upgraded from DISP=SHR to DISP=OLD. The system ends this job and issues message IEF211I.
Default: NO
The WAITALLOC option only applies to batch allocation requests (that is, allocation requests specified in the job's JCL).
SPACE
Specifies the installation defaults for some space allocation parameters. These defaults apply to only dynamic allocation and VIO requests. Understand that space allocations specified on JCL (for VIO requests), on dynamic allocation, or in SMS data classes take precedence over the values that are coded on this statement.
DIRECTORY(nnnnnnn)
Specifies the number of 256-byte records that are needed in the directory of a PDS.

When you are creating a PDS, you must request space for a directory.

Value range: 0 - 8388607.
Default: 0
MEASURE([TRK|CYL|AVEBLK])
Specifies the unit of measure of the space allocation.
AVEBLK
Requests that the system is to decide how many tracks to allocate based on the average block size. The size of the average block is specified using the BLKLNGTH parameter, and the number of blocks is specified using the PRIMARY parameter.
BLKLNGTH(nnnnn)
Specifies, in bytes, the average block length of the data. The system computes how many tracks to allocate.
Value range: 0 - 65535
Default: 8192
ROUND|NOROUND
When MEASURE(AVEBLK) is specified, requests whether (ROUND) or not (NOROUND).
Default: NOROUND
PRIM_ORG([CONTIG|MXIG|ALX])
Specifies the organization of the primary space allocation.
ALX
Requests that up to five of the largest separate areas of available contiguous space are to be allocated to the data set, and each area must be equal to or greater than the value specified on the PRIMARY parameter.

For example, assume the following space extents (in tracks) are available: 910, 435, 201, 102, 14, 12, and 8.

If your job requests 14 tracks as its primary allocation, and ALX is in effect, the job receives the following five extents: 910, 435, 201, 102, and 14.

However, if the job requests 15 tracks as its primary allocation, it would receive four extents: 910, 435, 201, and 102. The job does not receive the 14-track extent because it is less than the primary space allocation.

Be careful when you are coding this parameter. Large amounts of storage could be allocated, depending on how much free space is available at the time the request is made. If you code this parameter, also code the RLSE parameter to release any unused space.

Note: ALX can also be specified in a job's JCL.
CONTIG
Requests that space allocated to the data set be contiguous. If CONTIG is specified and contiguous space is not available, the system ends the job step.
MXIG
Requests that space allocated to the data set must be the largest area of available contiguous space on the volume and equal to or greater than the value specified on the PRIMARY parameter.
CAUTION:
Use extreme care with this parameter. Large amounts of storage might be allocated, depending on how much free space is available at the time the request is made. If you code this parameter, also code the RLSE parameter to release any unused space.

Do not code MXIG for an indexed sequential data set.

MXIG can also be specified in a job's JCL.

Default: None.
RLSE|NORLSE
Requests whether (RLSE) or not (NORLSE) space that is allocated to an output data set, but not used, is to be released when the data set is closed, and the CLOSE macro does not specify TYPE=T. Unused space is released only if the data set is OPEN with the OUTPUT, OUTIN, INOUT, EXTEND or OUTINX option, and the last operation was OPEN, WRITE (and CHECK), PUT, or CLOSE with TYPE=T. Coding RLSE for primary allocation does not prohibit use of secondary allocation. The secondary request for space is still in effect.
The system ignores a request to release unused space when a data set is closed if any of the following situations occur:
  • Another job is sharing the data set.
  • Another task in the same job is processing an OPEN, CLOSE, EOV, or FEOV request for the data set.
  • Another data control block is open for the data set.
  • The data set is an indexed sequential data set.
Default: RLSE
Default: AVEBLK
PRIMARY(nnnnnnn)
Specifies one of the following:
  • For TRK, the number of tracks to be allocated.
  • For CYL, the number of cylinders to be allocated.
  • For AVEBLK, the number of average data blocks in the data set. Use the BLKLNGTH parameter to specify the length of the average data block.

When you specify TRK or CYL for a partitioned data set (PDS), the primary quantity includes the space for the directory. When you specify a block length for a PDS, the primary quantity does not include the directory space; the system assigns the directory space outside the primary space assignment.

One volume must have enough available space for the primary quantity. If you request a particular volume and it does not have enough space available for your request, the system ends the job step. Allow for track overflow when computing track requirements.

To request an entire volume, specify in the primary quantity the number of tracks or cylinders on the volume minus the number used by the volume table of contents (VTOC). The volume must not contain other data sets.

Value range: 0 - 16777215
Default: 4
SECONDARY(nnnnnnn)
Specifies the number of additional tracks, cylinders, blocks, or records to be allocated, if more space is needed. The system does not allocate additional space until it is needed.
If PRIMARY specifies the average block length, the system computes the number of tracks for the secondary quantity from the SECONDARY value multiplied by one of the following, in order:
  1. The SPACE average block length subparameter.
  2. The block length in the BLKSIZE field of the data control block.
When you specify SECONDARY and the data set requires additional space, the system allocates the specified quantity:
  1. In contiguous tracks or cylinders, if available.
  2. If not, in up to five extents.

The system can allocate up to 16 extents for a data set on a volume. An extent is space that might or might not be contiguous to other space allocated to the data set. The extents for a data set include the primary quantity space and user-label space.

Note: BDAM data sets cannot be extended.
After the program fills the allocated space on a volume for a sequential data set, the system determines where the following data is written as follows:
  • If the disposition of the data set is NEW or MOD and the limit on the number of extents on a volume has not been reached, the system attempts to allocate the secondary quantity on the same volume.
  • If the disposition of the data set is OLD or SHARE, the system examines the next volume that is specified for the data set.
    • If space was allocated on the next volume for the data set, the next volume is used for the data set.
    • If space was not allocated on the next volume for the data set, secondary space is allocated on the next volume for the data set.
    • If there is not another volume that is specified for the data set, the system attempts to allocate the secondary quantity on the current volume.

    The program should not write with a disposition of DISP=SHR unless you take precautions to prevent other programs from writing at the same time.

If the requested volumes have no more available space and if at least one volume is demountable, the system asks the operator to mount scratch (nonspecific) volumes until the secondary allocation is complete. If none of the volumes are demountable, the system abnormally ends the job step.

Value range: 0 - 16777215
Default: 24
SPEC_WAIT
Specifies the installation policy to be followed when an allocation request must wait for a specific volume or unit.
MAXNWAIT(nnn)
Specifies the number of WAITNOH decisions allowed to be made for the specific volume or unit allocation request before the default specified on the POLICYNW parameter takes effect. The WAITNOH decisions counted are those that are specified either through the default on the POLICY parameter or through an installation exit that is specified in the EXITxx parmlib member. WAITNOH decisions that are made by the operator are not included in the MAXNWAIT count.
Value range: 1 - 255
Default: 5
POLICY ([WTOR|WAITHOLD|WAITNOH|CANCEL])
Specifies the default action to take. An installation exit can override the policy.
CANCEL
The installation policy is to cancel the allocation request. If a TSO/E user issued the allocation request, the user receives an error message. If a batch job or started task issued the request, the system cancels the job or task, releases its resources, and issues message IEF251I.
WAITHOLD
The installation policy is for the system to not release any of the devices that have already been allocated to this job before it waits for the required units or volumes. The system issues message IEF289E.

Using the WAITHOLD policy might cause a deadlock situation, particularly when the device is being used by a job that is going to wait. The system does not release any non-sharable devices (that is, non-DASD) that have already been allocated to the job before it waits for required units and volumes. To avoid this problem, do not specify WAITHOLD.

When devices for a job are held during a wait, and a device that was eligible for allocation to the job becomes ineligible for allocation (because of its use by a system utility, for example), the job might fail because it does not have enough devices to complete successfully. Message IEF700I in the job log identifies this failure. See message IEF700I for information about how to respond to this failure.

WAITNOH
The installation policy is to let the job wait while not holding the obtained resources. The system releases those devices that were allocated to this job, but that cannot be shared with other jobs. The system issues message IEF289E.
For an example of the WAITHOLD versus WAITNOH options, consider that JOBA owns an automatically switchable device and is waiting for a printer. JOBB owns the printer JOBA needs and is waiting for the automatically switchable device JOBA owns.
  • If the reply is WAITHOLD for each job, the two jobs wait until one job is canceled. This deadlock can be even more complex depending on the number of jobs that are waiting.
  • If the reply is WAITNOH for each job, allocation responds on a first-come, first-served basis. After the first job finishes using a resource, it is available to the second.
WTOR
The installation policy is to issue the message and let the operator make the decision about the wait request. The system displays one or more of the following messages on the operator's console:
  • IEF238D - Reply [device name] [,] [‘wait’] or ‘cancel’
  • IEF244I - Unable to allocate <nnn> units. At least <nnn> allocated or offline units are needed.
  • IEF433D - Wait requested. Reply hold or nohold.
  • IEF488I - Must wait for a unit, or volume on unit.
In addition, the system issues one or more of the following messages in response to an invalid reply to the preceding messages.
  • IEF434D - Invalid reply (to message IEF433D). Reply hold or nohold.
  • IEF490I - Invalid reply (to message IEF238D) for one of the following reasons:
    • Device is not accessible. No paths are available, boxed, or cannot be assigned.
    • Required system-managed volume is not available.
    • Required volume is not available.
    • Replied device is not eligible.
    • Device is found in an offline library.
    • Coupling facility error.
Default: WTOR
POLICYNW(CANCEL|WTOR)
Specifies how the system should handle the allocation request under the following circumstances:
  • Either WAITHOLD or WAITNOH is specified on the POLICY parameter and the system does not allow the job to wait for resources.
  • The maximum number of WAITNOH decisions (specified on the MAXNWAIT parameter) was exceeded.
CANCEL
Cancels the allocation request depending on how the request was issued. If a TSO/E user issued the allocation request, the user receives an error message. If a batch job or started task issued the request, the system cancels the job or task, releases its resources, and issues message IEF251I.
WTOR
Issues a write to operator with reply (WTOR) message. The system issues the messages listed earlier under WTOR.
Default: WTOR
SYSTEM
Specifies the system defaults.
BATCH_RCLMIGDS
Specifies how migrated data sets are recalled.
PARALLEL
The system notes which data sets are migrated and recalls them in parallel. Using this option might reduce job execution time.
SERIAL
The system allows the CATALOG LOCATE function to recall data sets on its behalf, resulting in serial recall processing.
Default: SERIAL
IEFBR14_DELMIGDS(LEGACY|NORECALL)
Specifies the policy on whether to recall a migrated data set when you use an IEFBR14 JCL program with DD DISP=(x,DELETE) to delete the data set. The recall is, in most cases, unnecessary, as the data set is being deleted anyway.
LEGACY
Indicates that the system is to recall HSM-migrated data sets before deletion.
NORECALL
Indicates that the system can delete (through HSM HDELETE processing) the data set without first recalling the data set to the primary storage.
Default: LEGACY
MEMDSENQMGMT(ENABLE|DISABLE)
Specifies if the MEMDSENQMGMT feature is available for exploitation by jobs and subsystems.
DISABLE
Disables jobs and subsystems from using memory-based data set ENQ management for dynamically allocated data sets.
ENABLE
Allows jobs and subsystems to use memory-based data set ENQ management for dynamically allocated data sets. Memory-based data set ENQ management is faster than the other option, SWA-based data set ENQ management, for jobs that allocate a large number of data sets. In addition to the parmlib setting, a job or subsystem that is to use the new management system must enable the feature using the IEFDDSRV service (for example, IEFDDSRV MODIFY TYPE=FEATURE,DSENQMGMT=MEMORY). Note that this feature makes the job or subsystem non-restartable through the checkpoint/restart interface.
Default: DISABLE
OPTCDB_SPLIT(EXPLICIT|CATALOG)
Specifies how Allocation should process requests for data sets whose volumes reside in one or more system-managed tape libraries when DCB=OPTCD=B is specified. See the description of OPTCD=B in z/OS MVS JCL Reference and Data sets that span libraries in z/OS MVS JCL User's Guide for additional information about using DCB=OPTCD=B.
EXPLICIT
Indicates that when OPTCD=B is specified for a multi-volume tape data set in one or more system-managed tape libraries, the data set is eligible to be allocated as a concatenation of individual volumes when volume serial numbers are explicitly specified on the request. Requests where the volume information is retrieved from the catalog are not eligible to be allocated as a concatenation.
CATALOG
Indicates that when OPTCD=B is specified for a multi-volume tape data set in one or more system-managed tape libraries, the data set is eligible to be allocated as a concatenation of individual volumes when volume serial numbers are explicitly specified on the request or when the volume information is retrieved from the catalog.
Default: EXPLICIT
REMIND_INTV(xxx)
Specifies the number of seconds for how often the message IEF882E and IEF883E are displayed, letting an operator know of an outstanding IEF238D, IEF433D, or IEF434D message. This interval indicates how many seconds between reminder messages, or 0 to disable them.
Value range: 0 or 10-999
Default: 90
Start of changeSWBSTORAGE(SWA|ATB)End of change
Start of change

Defines whether Scheduler Work Blocks (SWBs) for dynamically allocated data sets are eligible to be placed in 64-bit storage.

SWA

Indicates that SWBs will be created in 24 or 31 bit storage, according to the SWA definition in use by the job.

ATB

Indicates that SWBs are eligible to be created in 64 bit storage. Programs must indicate that they support SWBs in 64-bit storage by enabling the IEFDDSRV feature SWBSTORAGE=ATB.

End of change
TAPELIB_PREF(EQUAL|BYDEVICES)
Specifies the policy for balancing non-specific tape library requests (for example, scratch tape requests) across multiple tape libraries.
EQUAL
Indicates that for nonspecific tape library requests, all tape libraries must be treated as equal, and receive an equal share of the requests.
BYDEVICES
Indicates that non-specific tape library requests must be balanced across all tape libraries according to the number of online and unallocated tape devices in the tape library. Tape libraries with more online tape devices receive more non-specific tape requests than libraries with fewer online devices when all devices have the same attributes.

This setting is useful when there are multiple tape libraries with different numbers of online tape devices. A tape library with, for example, 512 online tape devices would be able to handle more requests than a tape library with only 16 online tape devices. This setting allows MVS™ Device Allocation to better balance the requests across dissimilar libraries.

It is recommended that you use the BYDEVICES option when using the system-managed tape libraries.

Default: EQUAL
TEMPDSFORMAT(UNIQUE|INCLUDELABEL)
Specifies how the system generates data set names for temporary data sets that include &&label as the specified data set name. This statement affects only the data sets that specify DSN=&&mydsn, but not the data sets that do not specify DSNAME at all.
INCLUDELABEL
Indicates that when the system processes JCL that includes temporary data sets with DSN=&&LABEL, the generated data set name includes the &&label specified in the JCL. See z/OS MVS JCL Reference for more information.
Note: When this parameter is specified and the Job Entry Subsystem (JES) allows multiple jobs with the same job name to execute at the same time, jobs with the same name, executing simultaneously, might fail with a duplicate data set name error.
UNIQUE
Indicates that when the system processes JCL that includes temporary data sets with DSN=&&LABEL, the generated data set name is in the form SYSyyddd.Thhmmss.RA000.jjobname.Rggnnnnn, which does not include the &&label that is specified in the JCL. All references to &&mydsn throughout the JCL correctly refer to the same data set. Using TEMPDSFORMAT=UNIQUE ensures that jobs with the same job name running simultaneously do not create temporary data sets with the same names. See z/OS MVS JCL Reference for more information.
Default: INCLUDELABEL
VERIFY_UNCAT(FAIL|TRACK|MSGTRACK|LOGTRACK)
Specifies the policy for handling UNCATLG requests in JCL and dynamic allocation when the data set information is not retrieved from the catalog.
FAIL
Fails the request. This option prevents a job from accidentally uncataloging a cataloged data set with the same name as the data set that is allocated.
LOGTRACK
Allows the data set to be uncataloged, tracks the request in the tracking facility, and issues a message. Specifying this option allows a job to uncatalog a cataloged data set with the same name as the data set that is allocated. This option is provided for migration purposes to assist you in finding and correcting the existing JCL that might have been uncataloging data sets incorrectly. It might be removed from the system in the future.
The tracking facility must be active for UNCATLG requests to be tracked. When a job attempts to uncatalog a data set for which the data set information is not retrieved from the catalog, the job is tracked with the Tracking information containing the string IEFALC 01, followed by the step name and the DD name.
  • For batch allocated DDs, the program name contains IEFIIC.
  • For dynamically allocated DDs, the program name is the offending program if it can be determined, or SVC-099 if it cannot be determined.
  • The VALUE field is unused, and contains zeros.

Instances of the IEFALC 01 event should be corrected by the installation, rather than reported to IBM®. For more information about the tracking facility, see z/OS MVS Planning: Operations.

In addition to tracking the event, message IEF384I indicates that the data set is uncataloged, but the volume information is not retrieved from the catalog. This message informs the submitter of the job that the JCL should be corrected. For more information, see z/OS MVS System Messages, Vol 8 (IEF-IGD).

MSGTRACK
Allows the data set to be uncataloged, tracks the request in the tracking facility, and issues a message. Specifying this option allows a job to uncatalog a cataloged data set with the same name as the data set that is allocated. This option is provided as a migration option to assist the installation in finding and correcting the existing JCL that might have been uncataloging data sets incorrectly.
Note: This option is provided for migration purposes. It might be removed from the system in the future.
The tracking facility must be active for UNCATLG requests to be tracked. When a job attempts to uncatalog a data set for which the data set information is not retrieved from the catalog, the job is tracked with the Tracking information containing the string IEFALC 01, followed by the step name and the DD name.
  • For batch allocated DDs, the program name contains IEFIIC.
  • For dynamically allocated DDs, the program name is the offending program if it can be determined, or SVC-099 if it cannot be determined.
  • The VALUE field is unused, and contains zeros.

Instances of the IEFALC 01 event should be corrected by the installation, rather than reported to IBM. For more information about the tracking facility, see z/OS MVS Planning: Operations.

In addition to tracking the event, message IEF384I indicates that the data set is uncataloged, but the volume information is not retrieved from the catalog. This message informs the submitter of the job that the JCL should be corrected. For details, see z/OS MVS System Messages, Vol 8 (IEF-IGD).

TRACK
Allows the data set to be uncataloged, and tracks the request in the tracking facility. Specifying this option allows a job to uncatalog a cataloged data set with the same name as the data set that is allocated. This option is provided as a migration option to assist the installation in finding and correcting the existing JCL that might have been uncataloging data sets incorrectly.
Note: This option is provided for migration purposes. It might be removed from the system in the future.
The tracking facility must be active for UNCATLG requests to be tracked. Whenever a job attempts to uncatalog a data set for which the data set information is not retrieved from the catalog, the job is tracked with the Tracking information containing the string IEFALC 01, followed by the step name and the DD name.
  • For batch allocated DDs, the program name contains IEFIIC.
  • For dynamically allocated DDs, the program name is the offending program if it can be determined, or SVC-099 if it cannot be determined.
  • The VALUE field is unused, and contains zeros.

Instances of the IEFALC 01 event should be corrected by the installation rather than reported to IBM. For more information about the tracking facility, see z/OS MVS Planning: Operations.

Default: FAIL
TIOT
Specifies the installation defaults for the task I/O table (TIOT).
SIZE(nn)
Specifies the size of the TIOT. The TIOT contains an entry for each DD statement. The size of the TIOT controls how many DDs are allowed per job step. By specifying an integer from 16 to 64 as the value of this parameter, the installation controls the default DD allowance. Table 1 shows the relationship between the size of the TIOT and the maximum number of DDs allowed.
Table 1. Relationship size of TIOT and maximum number of DDs allowed
Dec Hex Size of TIOT Maximum number of single unit DD allowed Maximum number of DDs allowed when every DD requests the maximum number of units (59)
16 10 16384 (16 K) 816 64
17 11 17408 (17 K) 867 68
24 18 24576 (24 K) 1225 97
25 19 25600 (25 K) 1277 101
32 20 32768 (32 K) 1635 129
40 28 40960 (40 K) 2045 162
48 30 49152 (48 K) 2454 194
56 38 57344 (56 K) 2864 227
64 40 65536 (64 K) 3273 259
Notes:
  1. The calculations must take into account that the size of a TIOT entry, for a DD statement or a Dynamic Allocation, increases by four bytes for every SMS Candidate volume assigned (for example, by your DATACLAS), regardless of whether they are guaranteed space.
  2. For a VSAM KSDS, the number of 4-byte entries in the TIOT for the data set depends on whether the data set is defined as reusable. The count of entries in the TIOT is the count of candidate volumes for the data and index components plus:
    • For a reusable data set, the number of volumes that are used by the data component plus the number of volumes that are used by the index component.
    • For a nonreusable data set, the number of volumes in the set of volumes that are used by the data and index component.
  3. Use the following to calculate the maximum number of DDs allowed per job step:
    1. The TIOT Prefix, Header, and Trailer consume sixty (60) ('3C'x) bytes of the total TIOT space available to a Job Step.
    2. A DD statement requesting a single unit requires twenty (20) bytes ('14'x) of TIOT space. The TIOT space requirement for entire step is 80 bytes.
       //TAPEJOB   JOB
       //STEP1     EXEC   PGM=IEFBR14
       //DD1       DD     UNIT=3490     ** DD requires 20 bytes * 
    3. A DD statement requesting two units require 24 bytes ('18'x) of TIOT space. Twenty bytes for the basic information for the first unit and an additional four bytes for the second unit. The TIOT space requirement for entire step is 84 bytes.
       //TAPEJOB   JOB
       //STEP1     EXEC   PGM=IEFBR14
       //DD1       DD     UNIT=(3490,2) ** DD requires 24 bytes * 
    4. A DD requesting the maximum number of units allowed, fifty nine (59), utilizes two hundred fifty two (252) bytes ('FC'x) of TIOT space. The TIOT space requirement for entire step is 312 bytes.
       //TAPEJOB   JOB
       //STEP1     EXEC   PGM=IEFBR14
       //DD1       DD     UNIT=(3490,59) ** DD requires 252 bytes * 
    5. A job step with three DD statements and each DD requesting one more unit than the previous DD would use the following TIOT space. The TIOT space requirement for entire step is 132 bytes.
       //TAPEJOB   JOB
       //STEP1     EXEC   PGM=IEFBR14
       //DD1       DD     UNIT=3490      ** DD requires 20 bytes *
       //DD2       DD     UNIT=(3490,2)  ** DD requires 24 bytes *
       //DD3       DD     UNIT=(3490,3)  ** DD requires 28 bytes * 
Value range: 16 - 64 kilobytes
Default: 32 kilobytes
UNIT
Specifies the installation default for the device on which the system is to place data sets.
NAME(group-name)
Requests a group of devices to place data sets on. The installation must have assigned the name to the devices during system initialization or IBM must have assigned the name. This default applies only to dynamic requests.

A group name can identify a single device or a group of devices. A group can consist of devices of the same or different types. For example, a group can contain both direct access storage devices (DASD) and tape devices.

The system assigns any available device from the group. If a group consists of only one device, the system assigns that device. If the group consists of more than one device type, the units requested are allocated from the same device type. For example, if GPDA contains 3330 Disk Storage and 3350 direct access storage devices (DASD), a request for two units would be allocated to two 3330s or to two 3350s.

If a data set that was created using the group-name subparameter is to be extended, the system allocates additional devices of the same type as the original devices. However, the additional devices might not necessarily be from the same group.

Dynamic allocation consideration: If a time sharing user's dynamic allocation request does not include unit information, the system obtains a unit description from:

If the user is not a time sharing user, or if the SYS1.UADS entry does not contain a unit description, the system uses the unit name specified on the UNIT keyword of the ALLOCxx parmlib member as the default.

The unit description you supply in your dynamic allocation request can override the unit type for a cataloged data set. The unit description from the SYS1.UADS, however, cannot override the unit information in the catalog.

Value range: 1 to 8 alphanumeric characters.
Default: SYSALLDA, which contains all DASD defined to the system.
REDIRECTED_TAPE(TAPE|DASD)
Allows the installation to specify whether unopened batch-allocated DASD data sets that were redirected from tape should be treated as DASD or TAPE.

Specifying REDIRECTED_TAPE(TAPE) causes unopened batch allocated data sets that have been redirected from TAPE to DASD to be deleted during final disposition processing. These unopened redirected data sets are deleted regardless of the disposition requested.

Specifying REDIRECTED_TAPE(DASD) causes unopened batch allocated data sets that have been redirected from TAPE to DASD to be processed according to the original disposition, as they would have been if they had been directed to DASD and not redirected to DASD from TAPE.

Dynamic allocation of SMS DASD data sets that were redirected from TAPE continues to be treated as DASD during dynamic allocation.

Default: TAPE
UNITAFF(unit-name)
Specifies the installation default for the unit name on which the system is to place data sets when the following conditions are true:
  • The data set for the referencing DD, that is, the DD that specifies UNIT=AFF, DISP=NEW or DISP=MOD (MOD treated as NEW), and is not SMS-managed.
  • The data set for the referenced DD, that is, the DD statement pointed to by the UNIT=AFF subparameter, is SMS-managed.
  • The allocation is not part of a data set collection involving data set stacking.
  • The system cannot obtain a unit name from the primary DD statement in the unit affinity chain.

The installation must have assigned the name to the devices during system initialization, or IBM must have assigned the name.

The unit name can be a group name. A group-name can identify a single device or a group of devices. A group can consist of devices of the same or different types. For example, a group can contain both direct reel tape devices (3400) and cartridge tape devices (3480).

The system assigns any available device from the group. If a group consists of only one device, the system assigns that device. If the group consists of more than one device type, the units requested are allocated from the same device type. For example, if TAPEGRP contains both 3400 devices and 3480 devices, a request for two units would be allocated to two 3400s or to two 3480s.

If a data set that was created using the UNITAFF subparameter is to be extended, the system allocates additional devices of the same type as the original devices. However, the additional devices might not necessarily be from the same group.

If the name specified by UNITAFF does not exist in the eligible devices table (EDT), the system default is used instead and a warning message is issued.

Note: If the UNITAFF subparameter is not specified for any given system, make sure the device preference order is the same on all systems. In this case, a system-derived default is used, that is, the tape generic highest in the device preference table.
Value range: 1 to 8 alphanumeric characters.
Default: The tape generic that is highest t in the device preference table. This generic must be available on every IODF used on the system between this IPL and the next IPL.
VERIFY_VOL
Specifies the installation policy for verifying premounted or PASSed/RETAINed volumes on AutoSwitchable (AS) tape devices.

The OPEN, FEOV and CLOSE macros allow the specification of a positioning parameter, and that the LEAVE option of these macros is treated the same as RETAIN.

An AS Tape device that is connected, and possibly used, outside of this allocation's tape management scheme can be "stolen" for temporary use by allocation on a system outside this scheme and cause the volume status for the device to change, unbeknownst to this allocation's scheme. In this case, if the volume had been premounted, or is PASSed/RETAINed, this allocation scheme could then be causing inadvertent read/write activity on a volume. This can result in data loss or data integrity exposures.

If, for a given DD statement, MVS allocation selects an AS tape device and the UCB for that device shows any currently mounted volume to be the required volume for that DD, the system can optionally cause volume verification to occur when an OPEN is performed for that DD.

This becomes a significant consideration if:
  1. AS Tape devices within the scope of this allocation's tape management scheme are also connected to, and usable by, systems outside of that scheme.
  2. Allocation on this system might encounter volumes that are premounted onto an AS tape device or PASSed/RETAINed via JCL while mounted on an AS device.

Some examples of AS Tape devices that are connected outside the scope of allocation's tape management scheme include:

  1. AS tape devices online to LPARs running other operating systems, such as Linux® on z Systems® or z/VM®.
  2. AS tape devices online to at least one system in a sysplex and also online to one or more distinct, stand-alone systems.
  3. AS tape devices online to systems in two or more distinct sysplexes.
POLICY(YES|NO)
Specifies whether the system is to perform volume verification of an apparently premounted or PASSed/RETAINed AS tape device at open time.
NO
No specific volume verification is to be done by OPEN on premounted or PASSed/RETAINed volumes on an AS tape device. Only select this policy option if it is certain there is no exposure to the "stolen" AS device for premounted or PASSed/RETAINed volumes as described in the previous scenarios. For example, specify POLICY(NO) if all systems within a sysplex are z/OS® V1R2 or later, and tape devices that are defined as AS to systems within that sysplex are not shared with any systems, or sysplexes, outside of that sysplex.
YES
Volume verification is to be done by OPEN for Standard, ISO/ANSI Version 1, or ISO/ANSI/FIPS Version 3 labeled tape volumes that are premounted or PASSed/RETAINed on an AS tape device. Both volume serial and tape position are verified.
Default: YES
VOLUME_ENQ
Specifies the installation policy for enqueuing on volumes when an allocation request has to wait for a volume or a series of volumes.
POLICY ([WTOR|CANCEL|WAIT])
Specifies the default action to take. An installation exit can override the policy.
CANCEL
The installation policy is to cancel a job that needs an unavailable volume. The system cancels the job, releases its resources, and issues message IEF251I.
WAIT
The installation policy is to let a job that needs an unavailable volume wait until the volume is available.
Caution: When WAIT is used as the default, deadlocks with other jobs in the system might arise for tape volumes.
WTOR
The installation policy is to issue the message and let the operator make the decision about the allocation request. The system displays one of the following messages on the operator's console:
  • IEF690I - The following volumes are unavailable to <jobname>...
  • IEF235D - <jobname> is waiting for volumes. To cancel wait, reply no.

In addition, the system issues message IEF369D (invalid reply) in response to an invalid reply to IEF235D.

Default: WTOR
VOLUME_MNT
Specifies the installation policy for mounting a volume when an allocation request requires a volume to be mounted. MVS invokes the exit when processing mount requests for single volumes or the first volume of a multi-volume request. MVS does not invoke the exit for tape mount requests that specify UNIT=DEFER nor second and subsequent volumes of a multi-volume request. Use the EOV exit routine to handle second and subsequent volumes (see z/OS DFSMS Installation Exits for information).
POLICY ([WTOR|CANCEL])
Specifies the default action to take. An installation exit can override the policy.
CANCEL
The installation policy is to cancel a job that needs a volume mounted. The system cancels the job, releases its resources, and issues message IEF251I.
WTOR
The installation policy is to issue the message and let the operator make the decision about the volume mount. The system displays one or more of the following messages on the operator's console:
  • IEF233A (Mount volume <ser>.)
  • IEF233D (Mount volume <ser> or respond to IEF455D message.)
  • IEF455D (Mount <ser> on <device> for <jobname> or reply no.)
  • IEF488I (Must wait for a unit, or volume on unit).

In addition, the system issues message IEF369D (invalid reply) in response to an invalid reply to IEF455D.

Default: WTOR