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 nonspecific 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 that is 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 that are made by the operator
are not included in the MAXNWAIT count. Value range: 1 - 255Default: 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 nonsharable 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 might 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 deallocated data sets (data sets that have been
deallocated 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 deallocates 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.
- 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:
- The setting of the condition code is not affected.
- 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.
- 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:- This job plus one (or more) other jobs have the data set allocated as DISP=SHR.
- 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: NOThe 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 by using the BLKLNGTH parameter, and the number of
blocks is specified by 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 - 65535Default: 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 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.
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 that is 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 that is used by the volume table of contents (VTOC). The volume must not contain other data sets.
Value range: 0 - 16777215Default: 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 more 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 that is multiplied by one of the following, in order:
- The SPACE average block length subparameter.
- The block length in the BLKSIZE field of the data control block.
When you specify SECONDARY and the data set requires more space, the system allocates the specified quantity:- In contiguous tracks or cylinders, if available.
- 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 - 16777215Default: 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 that are allowed to be made for the specific volume or
unit allocation request before the default that is specified on the POLICYNW parameter takes effect.
The WAITNOH decisions that are 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 - 255Default: 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 nonsharable 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 whether 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 many data sets. In addition to the parmlib setting, a job or subsystem that is to use the new management system must enable the feature by using the IEFDDSRV service (for example, IEFDDSRV MODIFY TYPE=FEATURE,DSENQMGMT=MEMORY). Note that this feature makes the job or subsystem nonrestartable 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-999Default: 90
- SWBSTORAGE(SWA|ATB)
-
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.
- TAPELIB_PREF(EQUAL|BYDEVICES)
- Specifies the policy for balancing nonspecific 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 nonspecific tape library requests must be balanced across all tape libraries according to the number of online and deallocated tape devices in the tape library.
Tape libraries with more online tape devices receive more nonspecific 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 specifyDSN=&&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).
- For batch allocated DDs, the program name contains
- 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).
- For batch allocated DDs, the program name contains
- 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. - For batch allocated DDs, the program name contains
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 units 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:- The calculations must take into account that the size of a TIOT entry, for a DD statement or a Dynamic Allocation, increases by 4 bytes for every SMS Candidate volume assigned (for example, by your DATACLAS), regardless of whether they are guaranteed space.
- 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.
- Use the following to calculate the maximum number of DDs allowed per job step:
- The TIOT Prefix, Header, and Trailer consume 60 ('3C'x) bytes of the total TIOT space available to a Job Step.
- A DD statement requesting a single unit requires 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 *
- 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 4 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 *
- A DD requesting the maximum number of units allowed, fifty nine (59), uses 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 *
- 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 kilobytesDefault: 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 by 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:- 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. - 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 might 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:- 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.
- 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:
- AS tape devices online to LPARs running other operating systems, such as Linux® on z Systems® or z/VM®.
- AS tape devices online to at least one system in a sysplex and also online to one or more distinct, stand-alone systems.
- 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