Monday, 28 July 2014

COBOL Blocked vs Unblocked Records: FB, VB, and BLKSIZE

A COBOL statement such as READ CUSTOMER-FILE returns one logical customer record. The underlying QSAM access method might bring a physical block containing many customer records into a buffer during one I/O operation. Record blocking changes the physical transfer unit; it does not change the record-by-record interface used by ordinary COBOL logic.

COBOL blocked versus unblocked QSAM records showing logical records inside physical blocks
Blocking groups logical records for physical I/O; COBOL still reads one logical record.

What blocked and unblocked records mean

An unblocked non-VSAM data set stores one logical record in each physical block. A blocked data set can place several logical records in one physical block. The block is the unit transferred between the device and an I/O buffer. The record is the unit your program normally processes.

A block should not be described as a disk sector. Modern z/OS storage and access methods manage device geometry below the application interface, and one physical block is not defined as one sector. Use RECFM, LRECL, and BLKSIZE to describe the data set.

Programmer view: QSAM performs blocking and deblocking. Your sequential READ receives the next logical record even when the buffer contains several records from one block.

F, FB, V, and VB record formats

RECFMLogical recordPhysical blockTypical use
FFixed lengthOne logical record per blockUnblocked fixed records; seldom chosen for ordinary sequential files
FBFixed lengthSeveral equal-length records can share a blockCommon fixed-length QSAM data sets
VVariable length with a four-byte RDWOne logical record per blockUnblocked variable records; seldom chosen
VBVariable length; each record has an RDWSeveral records share a block that begins with a four-byte BDWCommon variable-length QSAM data sets

The B in FB or VB means blocked. Record length is a separate decision. The COBOL fixed-versus-variable record guide covers FD definitions, RDWs, and record layouts in more detail.

How blocking factor works for FB

For ordinary fixed blocked data, the blocking factor is the number of logical records that fit in one physical block:

FB blocking factor = BLKSIZE / LRECL
DCB valuesResult
RECFM=F,LRECL=100,BLKSIZE=100One 100-byte logical record in each block
RECFM=FB,LRECL=100,BLKSIZE=1000Ten 100-byte logical records in a full block
RECFM=FB,LRECL=100,BLKSIZE=0Request a system-determined block size when supported

For FB data, an explicit nonzero BLKSIZE must normally be an integral multiple of LRECL. A value of 950 with LRECL=100 is incompatible because it cannot hold a whole number of fixed records without unused trailing bytes.

Why VB blocking is different

A VB physical block begins with a four-byte block descriptor word (BDW). Each logical record begins with its own four-byte record descriptor word (RDW), and the records can have different lengths. Consequently, a VB data set does not have one constant blocking factor in the way an FB data set does.

For RECFM=VB,LRECL=404, the maximum logical record length is 404 bytes including the RDW. BLKSIZE is the maximum physical block length and must leave room for the BDW plus the records placed in that block. System-determined blocking avoids embedding a device-specific calculation in the job.

Records longer than a block require spanned formats rather than ordinary VB. See the JCL VBS and spanned-record guide for RDW segment rules and LRECL=X.

COBOL BLOCK CONTAINS 0 example

ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
    SELECT CUSTOMER-FILE ASSIGN TO CUSTIN
        ORGANIZATION IS SEQUENTIAL
        FILE STATUS IS WS-FILE-STATUS.

DATA DIVISION.
FILE SECTION.
FD  CUSTOMER-FILE
    RECORDING MODE IS F
    BLOCK CONTAINS 0 RECORDS
    RECORD CONTAINS 100 CHARACTERS.
01  CUSTOMER-RECORD PIC X(100).

For a QSAM file, BLOCK CONTAINS 0 RECORDS defers the block-size choice until run time. An existing input data set can supply the value through its data set label or DD information. For a new output data set, omitting an explicit block size allows z/OS to select a system-determined block size where supported.

BLOCK CONTAINS 1 RECORD is not the same declaration as omitting blocking. IBM states that coding one record still results in fixed blocked records. If the clause is omitted, the Enterprise COBOL default is unblocked unless the BLOCK0 compiler option applies.

The COBOL sequential-file FD guide explains the neighboring RECORD CONTAINS, LABEL RECORDS, and record-description entries.

JCL DCB examples

New fixed blocked output file

//CUSTOUT DD DSN=APP.CUSTOMER.NEW,
//            DISP=(NEW,CATLG,DELETE),
//            SPACE=(CYL,(5,2)),
//            DCB=(RECFM=FB,LRECL=100,BLKSIZE=0)

This DD requests fixed blocked records with 100-byte logical records and lets the system select the physical block size. The data class and installation settings can also participate in allocation.

New variable blocked output file

//TXNOUT  DD DSN=APP.TRANSACTION.NEW,
//            DISP=(NEW,CATLG,DELETE),
//            SPACE=(CYL,(5,2)),
//            DCB=(RECFM=VB,LRECL=404,BLKSIZE=0)

Here, 404 is the maximum logical record length including the RDW. The actual application data portion can be at most 400 bytes. Do not add a second four bytes in the COBOL record description for the RDW; QSAM manages it.

Existing input: avoid overriding cataloged DCB attributes just to make a job run. The program description and actual data set must agree. A mismatch can fail OPEN, often with a nonzero file status such as 39.

BLOCK0 and AWO are related but different

The Enterprise COBOL BLOCK0 option can apply an implicit BLOCK CONTAINS 0 to eligible QSAM sequential files whose FD omits the clause. Its compiler default is NOBLOCK0, although an installation can set and fix compiler options. Check the option listing used for the module rather than assuming the site default.

AWO controls when a variable blocked output buffer is written when APPLY WRITE-ONLY is relevant. It does not select the block size. The COBOL AWO compiler-option guide keeps that separate performance intent.

When blocked records help

  • Sequential throughput: one physical transfer can place several logical records in a buffer, reducing I/O requests for a large sequential pass.
  • Storage use: larger, well-chosen blocks reduce the proportion of device space and processing spent on physical block handling.
  • Device movement: system-determined blocking can be recalculated when a data set moves to a different supported device type.

Blocking does not remove the need to measure the job. Buffer count, access pattern, device type, data class, compression, and downstream consumers can affect results. Use job accounting data and EXCP counts when investigating an I/O-bound step.

When unblocked records may be required

Use an unblocked format when an interface or existing data set explicitly requires one logical record per physical block. Compatibility with an external producer, consumer, utility, or interchange rule can be more important than reducing I/O calls. Confirm the contract before changing F to FB or V to VB.

Blocking applies to non-VSAM sequential processing. IBM states that BLOCK CONTAINS has no execution effect for VSAM files. VSAM manages control intervals and control areas instead of QSAM-style record blocks.

Common record-blocking mistakes

  • Calling a physical block a sector and assuming a one-to-one hardware mapping.
  • Confusing record length with block size.
  • Using an FB BLKSIZE that is not divisible by LRECL.
  • Forgetting the four-byte RDW in a VB LRECL calculation.
  • Treating a VB file as if every block contains the same number of records.
  • Changing JCL DCB values without checking the COBOL FD and cataloged attributes.
  • Expecting BLOCK CONTAINS to tune a VSAM data set.
  • Assuming BLOCK0 and AWO perform the same function.

Record-blocking checklist

  1. Identify whether the file is QSAM, VSAM, a spool file, or another type.
  2. Confirm RECFM, LRECL, and BLKSIZE with data set information.
  3. Match the COBOL FD and record description to the actual file.
  4. Prefer BLOCK CONTAINS 0 or a governed BLOCK0 setting for eligible QSAM output when system-determined blocking fits the interface.
  5. Test every downstream reader before changing an established record format.
  6. Measure the affected batch step instead of assuming a performance gain.

The COBOL sequential-file guide shows the complete OPEN, READ, WRITE, and EOF flow, while the COBOL file-operations guide covers file modes and status handling.

Official IBM references

COBOL blocked vs unblocked records FAQ

What is a blocked record in COBOL?

For a non-VSAM QSAM file, blocking groups multiple logical records into one physical block. COBOL still presents one logical record to each sequential READ.

How is the blocking factor calculated for an FB data set?

For fixed blocked records, divide BLKSIZE by LRECL. Both values must be compatible, and BLKSIZE must be an integral multiple of LRECL for ordinary FB data sets.

What does BLOCK CONTAINS 0 RECORDS mean?

For a QSAM file, it lets the block size be determined at run time from the DD definition or data set attributes. For a new output data set with no explicit block size, z/OS can select a system-determined block size.

Does BLOCK CONTAINS affect VSAM files?

No. IBM states that the blocking concept does not apply to VSAM files; the clause can be syntax checked but has no execution effect for a VSAM file.

Keep the two units separate during diagnosis: COBOL processes logical records, while QSAM and z/OS manage the physical blocks that carry them.

No comments:

Post a Comment

New In-feed ads