z/OS DFSMS Using Data Sets
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


System-Determined Block Size

z/OS DFSMS Using Data Sets
SC23-6855-00

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:

  1. 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.
  2. 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.
  3. 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:

  1. BLKSZLIM value in the DD statement or dynamic allocation.
  2. 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.
  3. 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).
  4. 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

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014