Setting block sizes

Blocking QSAM files on tape and disk can enhance processing speed and minimize storage requirements. You can block files in the z/OS® UNIX file system, PDSE members, and spooled data sets, but doing so has no effect on how the system stores the data.

If you set the block size explicitly in the BLOCK CONTAINS clause, the size must not be greater than the maximum block size for the device. If you specify the CHARACTERS phrase of the BLOCK CONTAINS clause, size must indicate the number of bytes in a record regardless of the USAGE of the data items in the record. The block size that is set for a format-F file must be an integral multiple of the record length.

If your program uses QSAM files on tape, use a physical block size of at least 12 to 18 bytes. Otherwise, the block will be skipped over when a parity check occurs during one of the following actions:

• Reading a block of records of fewer than 12 bytes
• Writing a block of records of fewer than 18 bytes

Larger blocks generally give you better performance. Blocks of only a few kilobytes are particularly inefficient; you should choose a block size of at least tens of kilobytes. If you specify record blocking and omit the block size, the system will pick a block size that is optimal for device utilization and for data transfer speed.

Letting z/OS determine block size: To maximize performance, do not explicitly set the block size for a blocked file in your COBOL source program. For new blocked data sets, it is simpler to allow z/OS to supply a system-determined block size. To use this feature, follow these guidelines:

• Code BLOCK CONTAINS 0 in your source program or compile with the BLOCK0 option. For details about BLOCK0, see BLOCK0.
• Do not code RECORD CONTAINS 0 in your source program.
• Do not code a BLKSIZE value in the JCL DD statement.

Setting block size explicitly: If you prefer to set a block size explicitly, your program will be most flexible if you follow these guidelines:

• Code BLOCK CONTAINS 0 in your source program or compile with the BLOCK0 option.
• Code a BLKSIZE value in the ddname definition (the JCL DD statement).

For extended-format data sets on z/OS, z/OS DFSMS adds a 32-byte block suffix to the physical record. If you specify a block size explicitly (using JCL or ISPF), do not include the size of this block suffix in the block size. This block suffix is not available for you to use in your program. z/OS DFSMS allocates the space used to read in the block suffix. However, when you calculate how many blocks of an extended-format data set will fit on a track of a direct-access device, you need to include the size of the block suffix in the block size.

If you specify a block size that is larger than 32760 directly in the BLOCK CONTAINS clause or indirectly with the use of BLOCK CONTAINS n RECORDS, the OPEN of the data set fails with file status code 90 unless you define the data set to be on tape.

For existing blocked data sets, it is simplest to:

• Code BLOCK CONTAINS 0 in your source program or compile with the BLOCK0 option.
• Not code a BLKSIZE value in the ddname definition.

When you omit the BLKSIZE from the ddname definition, the block size is automatically obtained by the system from the data-set label.

Taking advantage of LBI: You can improve the performance of tape data sets by using the large block interface (LBI) for large block sizes. When the LBI is available, the COBOL run time automatically uses this facility for those tape files for which you use system-determined block size. LBI is also used for those files for which you explicitly define a block size in JCL or a BLOCK CONTAINS clause. Use of the LBI allows block sizes to exceed 32760 if the tape device supports it.

The LBI is not used in all cases. An attempt to use a block size greater than 32760 in the following cases is diagnosed at compile time or results in a failure at OPEN:

• Spanned records
• OPEN I-O

Using a block size that exceeds 32760 might result in your not being able to read the tape on another system. A tape that you create with a block size greater than 32760 can be read only on a system that has a tape device that supports block sizes greater than 32760. If you specify a block size that is too large for the file, the device, or the operating system level, a runtime message is issued.

To limit a system-determined block size to 32760, do not specify BLKSIZE anywhere, and set one of the following items to 32760:

• The BLKSZLIM keyword on the DD statement for the data set
• BLKSZLIM for the data class by using the BLKSZLIM keyword (must be set by your systems programmer)
• A block-size limit for the system in the DEVSUPxx member of SYS1.PARMLIB by using the keyword TAPEBLKSZLIM (must be set by your systems programmer)

The block-size limit is the first nonzero value that the compiler finds by checking these items.

If no BLKSIZE or BLKSZLIM value is available from any source, the system limits BLKSIZE to 32760. You can then enable block sizes larger than 32760 in one of two ways:

• Specify a BLKSZLIM value greater than 32760 in the DD statement for the file and use BLOCK CONTAINS 0 in your COBOL source.
• Specify a value greater than 32760 for the BLKSIZE in the DD statement or in the BLOCK CONTAINS clause in your COBOL source.

BLKSZLIM is device-independent.

Block size and the DCB RECFM subparameter: Under z/OS, you can code the S or T option in the DCB RECFM subparameter:

• Use the S (standard) option in the DCB RECFM subparameter for a format-F record with only standard blocks (ones that have no truncated blocks or unfilled tracks in the file, except for the last block of the file). S is also supported for records on tape. It is ignored if the records are not on DASD or tape.

  Using this standard block option might improve input-output performance, especially for direct-access devices.

• The T (track overflow) option for QSAM files is no longer useful.