If you do not specify a block size for the creation of a data set,
the system attempts to determine the block size. Using a system-determined
block size has the following benefits:
- The program can write to DASD, tape, or SYSOUT without you or
the program calculating the optimal block size. DASD track capacity
calculations are complicated. Optimal block sizes differ for various
models of DASD and tape.
- If the data set later is moved to a different DASD type, such
as by DFSMShsm, the system recalculates an appropriate block size
and reblocks the data.
The system determines the block size for a data set as follows:
- OPEN calculates a block size.
Note: A
block size may be determined during initial allocation of a DASD data
set. OPEN will either use that block size or calculate a new block
size if any of the data set characteristics (LRECL,RECFM) were changed
from the values specified during initial allocation.
- OPEN compares the calculated block size to a block size limit,
which affects only data sets on tape because the minimum value of
the limit is 32 760.
- OPEN attempts to decrease the calculated block size to be less
than or equal to the limit.
The block size limit is the first nonzero value from the following
items:
- BLKSZLIM
value in the DD statement or dynamic allocation.
- Block
size limit in the data class. The SMS data class ACS routine can assign
a data class to the data set. You can request a data class name with
the DATACLAS keyword in the DD statement or the dynamic-allocation
equivalent. The data set does not have to be SMS managed.
- TAPEBLKSZLIM value in the DEVSUPxx member
of SYS1.PARMLIB. A system programmer sets this value, which is in
the data facilities area (DFA) (see z/OS DFSMSdfp Advanced Services).
- The minimum block-size limit, 32 760.
Your
program can obtain the BLKSZLIM value that is in effect by issuing
the RDJFCB macro with the X'13' code (see z/OS DFSMSdfp Advanced Services).
Because larger blocks generally cause data transfer to be faster,
why would you want to limit it? Some possible reasons follow:
- A user will take the tape to an operating system or older z/OS system
or application program that does not support the large size that you
want. The other operating system might be a backup system that is
used only for disaster recovery. An OS/390® system
before Version 2 Release 10 does not support the large block interface
that is needed for blocks longer than 32 760.
- You want to copy the tape to a different type of tape or to DASD
without reblocking it, and the maximum block size for the destination
is less than you want. An example is the IBM 3480 Magnetic Tape Subsystem,
whose maximum block size is 65 535. The optimal block size for an
IBM 3590 is 224 KB or 256 KB, depending on the level of the hardware.
To copy from an optimized 3590 to a 3480 or 3490, you must reblock
the data.
- A program that reads or writes the data set and runs in 24-bit
addressing mode might not have enough buffer space for very large
blocks.
Table 1 describes block size support.
Table 1. Optimum and maximum block size supported| Device Type |
Optimum |
Maximum |
|---|
| DASD |
Half track (usually) |
32 760 |
|---|
| Reel tape |
32 760 |
32 760 |
|---|
| 3480, 3490 |
65 535 |
65 535 |
|---|
| 3490 Emulation (VTS) |
262 144 (256 KB) |
262 144 (256 KB) |
|---|
| 3590 |
262 144 (256 KB) except on some older models
on which it is 229 376 (224 KB) |
262 144 (256 KB) |
|---|
| DUMMY |
16 |
5 000 000 |
|---|