Mainframe, MVS and zOS Discussion

How many work data sets can we specify at most in a step?

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 jobstep. By specifying an integer from 16 to 64 as the value of this parameter, the installation controls the default DD allowance.

The following table shows the relationship between the size of the TIOT and the maximum number of DDs allowed:

Maximum number
of DDs allowed
when every DD
Maximum number requests the
SIZE Value of single Unit maximum number

Code: Select all

Dec (Hex) Size of TIOT DDs allowed 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 

Notes:
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.
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.
Use the following to calculate the maximum number of DDs allowed per Job Step:
The TIOT Prefix, Header, and Trailer consume sixty (60) ('3C'x) bytes of the total TIOT space available to a Job Step.
A DD statement requesting a single unit requires twenty (20) bytes ('14'x) of TIOT space.
Example 1:

//TAPEJOB JOB
//STEP1 EXEC PGM=IEFBR14
//DD1 DD UNIT=3490 ** DD requires 20 bytes *


TIOT space requirement for entire step = 80 bytes.
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.
Example 2:

//TAPEJOB JOB
//STEP1 EXEC PGM=IEFBR14
//DD1 DD UNIT=(3490,2) ** DD requires 24 bytes *


TIOT space requirement for entire step = 84 bytes.
A DD requesting the maximum number of units allowed, fifty nine (59), utilizes two hundred fifty two (252) bytes ('FC'x) of TIOT space.
Example 3:

//TAPEJOB JOB
//STEP1 EXEC PGM=IEFBR14
//DD1 DD UNIT=(3490,59) ** DD requires 252 bytes *


TIOT space requirement for entire step = 312 bytes.
A Job Step with three (3) DD statements and each DD requesting one more unit than the previous DD would utilitize the following TIOT space:
//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 *


TIOT space requirement for entire step = 132 bytes.
Value Range: 16 - 64 kilobytes

Default: 32 kilobytes

William Collins wrote:Are you asking about a SORT, or some other specific utility, or generally?

enrico-sorichetti wrote:there is a global limit on the number of DDNAMES that can be used

ant that number depends also on two more variables,
the number of extents and the number of volumes allocated

the SYSTEM INITIALIZATION AND TUNING manual has the following details

But for the work dataset,

William Collins wrote:Generally, work datasets aren't used outside utilities and products. Where they are used, they are used for specific purposes, and the technical staff responsible for those utilities and products will know how to define/optimise their use.

For SORT it is mostly best to use dynamic allocation rather than specifying actual work datasets, as your SORT product can make estimates are run-time depending on some characteristics of the actual data for that run, usually avoiding excessive overallocation or fatal underallocation.

Your SORT documentation will contain some information about the allocation of work datasets.

Language-processing can require work datasets, and if you have very large sources, you may have to increase the amount of space on one or more work-datasets, but how those are used is so complex, I doubt there is any useful estimate. If a compiler, for instance, fails with space on a work dataset, get advice from your technical staff.

If you have a specific case, outline it. Generally, there is no possible answer to how to estimate "work" space.

enrico-sorichetti wrote:

But for the work dataset,

the system does not care / does not know about the use of a ddname/dataset

for the system all the ddnames/datasets are handled the same way, according to the jcl keywords

nicc wrote:Please read William's post carefully - word by word. Especiall the sentence that starts "For SORT it is mostly best..." and the paragraph starting "Your SORT documentation...". In the latter case you were meant to actually go and read it.

For SORT it is mostly best to use dynamic allocation rather than specifying actual work datasets, as your SORT product can make estimates are run-time depending on some characteristics of the actual data for that run, usually avoiding excessive overallocation or fatal underallocation.