Statements/parameters for ALLOCxx

• EXPDT — Batch JCL two-digit year Expiration Date Keyword.
• DALEXPDT — Dynamic Allocation Expiration Date specification short form.

POLICY(ALLOW)

Allow the data set allocation with no Expiration Date related message.

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.

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.

Default: POLICY(ALLOW)

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 may or may 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.

When your program has filled 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 specified for the data set.
  • If space has been allocated on the next volume for the data set, the next volume is used for the data set.
  • If space has not been 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 specified for the data set, the system attempts to allocate the secondary quantity on the current volume.

  Note that your 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

DIRECTORY(nnnnnnn)

Specifies the number of 256-byte records needed in the directory of a PDS.

Note: When 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 as one of the following:

TRK

Requests that space be allocated in tracks.

CYL

Requests that space be allocated in cylinders.

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) space allocated to the data set must be equal to an integral number of cylinders.

Default: NOROUND

Default: AVEBLK

PRIM_ORG([CONTIG|MXIG|ALX])

Specifies the organization of the primary space allocation as one of the following:

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 (1) the largest area of available contiguous space on the volume and (2) equal to or greater than the value specified on the PRIMARY parameter.

Caution: IBM® suggests that you use extreme care when 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, IBM suggests that you also code the RLSE parameter to release any unused space.

Note:

1. Do not code MXIG for an indexed sequential data set.
2. MXIG can also be specified in a job's JCL.

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 5 extents: 910, 435, 201, 102, and 14.

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

Caution: IBM suggests that you use extreme care when 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, IBM suggests that you also code the RLSE parameter to release any unused space.

Note: ALX can also be specified in a job's JCL.

Default: None

RLSE|NORLSE

Requests whether (RLSE) or not (NORLSE) space 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 for output and the last operation was a write. 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:

• 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

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.

Note: Dynamic allocation of SMS DASD data sets that were redirected from TAPE will continue to be treated as DASD during dynamic allocation.

Default: TAPE

NAME(groupname)

Requests a group of devices to place data sets on. The installation must have assigned the name to the devices(s) 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 may 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:

• The PDF_DEFAULT_UNIT parameter for certain ISPF/PDF data sets. See Data set allocation settings in z/OS ISPF Planning and Customizing for specific information.
• The SYS1.UADS entry for all other ISPF/PDF data sets and for all non-ISPF/PDF TSO data sets.

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.

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 device(s) during system initialization, or IBM must have assigned the name.

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: Tape generic highest in the device preference table. This generic must be available on every IODF used on the system between this IPL and the next IPL.

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 jobstep. 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 (16K)	816	64
17	11	17408 (17K)	867	68
24	18	24576 (24K)	1225	97
25	19	25600 (25K)	1277	101
32	20	32768 (32K)	1635	129
40	28	40960 (40K)	2045	162
48	30	49152 (48K)	2454	194
56	38	57344 (56K)	2864	227
64	40	65536 (64K)	3273	259

Note:

1. Your calculations need to take into account that the size of a TIOT entry, for a DD statement or a Dynamic Allocation, increases by four (4) bytes for every SMS Candidate volume assigned (e.g., by your DATACLAS), regardless of whether they're guaranteed space.
2. For a VSAM KSDS the number of 4-byte entries in the TIOT for the data set depends on whether or not 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 used by the data component plus the number of volumes used by the index component.
   • For a nonreusable data set - the number of volumes in the set of volumes 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 (2) units requires twenty four (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 (3) DD statements and each DD requesting one more unit than the previous DD would use the following TIOT space; 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

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).

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 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.

When NO is specified, the system cancels the job, releases its resources, and issues message IEF211I.

Note:

1. Use caution when specifying YES. Allowing jobs to wait for data set availability can cause deadlocks with other jobs in the system.
2. 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.
3. The WAITALLOC option only applies to batch allocation requests (that is, allocation requests specified in the job's JCL).

Default: NO

POLICY ([WTOR|CANCEL|WAIT])

Specifies the default action to take. An installation exit can override the policy.

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.

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.

Default: WTOR

POLICY ([WTOR|CANCEL])

Specifies the default action to take. An installation exit can override the policy.

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.

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.

Default: WTOR

POLICY ([WTOR|WAITHOLD|WAITNOH|CANCEL])

Specifies the default action to take. An installation exit can override the policy.

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(s). 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 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

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.

Be aware that 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. Refer to 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 will release those devices that have been 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 will wait until one job is canceled. This deadlock can be even more complex depending on the number of jobs 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.

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.

Default: WTOR

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 will take effect. The WAITNOH decisions counted are those that are specified either through the default on the POLICY parameter or through an installation exit specified in the EXITxx parmlib member. "WAITNOH" decisions made by the operator are not included in the MAXNWAIT count.

Value Range: 1 - 255

Default: 5

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) has been exceeded.

The system is to either cancel the allocation request (CANCEL) or issue a message (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

Note that 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.

POLICY ([WTOR|WAITHOLD|WAITNOH|CANCEL])

Specifies the default action to take. An installation exit can override the policy.

WTOR

The installation policy is to issue the message and let the operator make the decision 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(s). 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.

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.

Be aware that 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. Refer to 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 will release those devices that have been 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 will wait until one job is canceled. This deadlock can be even more complex depending on the number of jobs 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.

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.

Default: WTOR

MAXNWAIT(nnn)

Specifies the number of “WAITNOH” decisions allowed to be made for the allocation request before the default specified on the POLICYNW parameter will take 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

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

• 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.

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.

Note:

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 will not be 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

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 have been issued. If FAILJOB(YES) is also specified, the system terminates the job, releases its resources, and issues message IEF378I.

Default: NO

VERIFY_VOL

Specifies the installation policy for verifying premounted or PASSed/RETAINed volumes on AutoSwitchable (AS) tape devices.

Note that 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 zLinux or zVM.
2. AS tape devices online to at least one system in a sysplex and also online to one or more distinct, standalone 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.

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.

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 above, 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.

Default: YES

SYSTEM

Specifies the system defaults.

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

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 non-specific 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 tape devices in the tape library. Tape libraries with more online tape devices will 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.

Default: EQUAL

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

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.

UNIQUE

Indicates that when the system processes JCL that includes temporary data sets with DSN=&&LABEL, the generated data set name will be in the form "SYSyyddd.Thhmmss.RA000.jjobname.Rggnnnnn", which does not include the &&label 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 jobname running simultaneously do not create temporary data sets with the same names. See z/OS MVS JCL Reference for more information.

INCLUDELABEL

Indicates that when the system processes JCL that includes temporary data sets with DSN=&&LABEL, the generated data set name will include 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.

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.

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 may 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 will contain 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.

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 may 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 will contain 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).

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. 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 will contain 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).

Default: FAIL

MEMDSENQMGMT(ENABLE|DISABLE)

Specifies if the MEMDSENQMGMT feature is available for exploitation by jobs and subsystems.

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.

DISABLE

Disables jobs and subsystems from using memory-based data set ENQ management for dynamically allocated data sets.

Default: DISABLE

BATCH_RCLMIGDS

Specifies how migrated data sets will be recalled.

SERIAL

The system allows the CATALOG LOCATE function to recall data sets on its behalf, resulting in serial recall processing.

PARALLEL

The system notes which data sets are migrated and recalls them in parallel; this may reduce job execution time.

Default: SERIAL

OPTCDB_SPLIT(EXPLICIT|CATALOG)

Indicates that the system should treat multi-volume data sets in system-managed tape libraries as separate DD statements only when DCB=OPTCD=B is specified with explicit volume serial numbers.

EXPLICIT|CATALOG

Specifies volume serial numbers or catalog.

Default: EXPLICIT