The daily edition.

Scope and Overview

This article covers COBOL file compression mechanisms in Rocket Enterprise Developer / Enterprise Server 12.0 for Linux/UNIX.

In high-volume batch processing and transactional applications, indexed and sequential data files can consume substantial storage and disk I/O bandwidth. Rocket COBOL provides two distinct compression facilities managed through the Callable File Handler (ExtFH): record data compression via DATACOMPRESS and index node key compression via KEYCOMPRESS.

Understanding how these compiler directives alter file structure and runtime behavior is essential to avoid corrupted updates, runtime abends, or unintended global compression across unrelated files.

Data Compression Mechanics and Sequential File Structural Transformation

As documented in Data Compression, data compression operates on sequential and indexed files by compressing repeated byte patterns before writing records to disk.

The DATACOMPRESS"integer" directive accepts specific integer algorithms:

• 0: Disables data compression (NODATACOMPRESS, the system default).
• 1: Run-Length Encoding (RLE), where any sequence of repeating characters is stored as a single character paired with a repetition count.
• 3: Extended run-length encoding optimized for double-byte character sets (DBCS).
• 128 through 255: Invokes user-defined compression routines.

The Fixed-to-Variable Transformation and REWRITE Limitation

When data compression is specified for a fixed-structure sequential file, the runtime file handler implicitly transforms the physical file structure into a variable-format sequential file.

Because compressed records vary in length depending on how effectively repeating bytes collapse, using the REWRITE statement on compressed sequential files is strongly discouraged. A REWRITE operation will succeed only if the length of the compressed replacement record exactly matches the length of the compressed original record. If the replacement record compresses to a different byte length, the REWRITE operation fails.

Key Compression and Additive Bitmask Values

While data compression shrinks record data payloads, Key Compression optimizes the index structure (.idx) of indexed files. It compresses key values stored within index B-tree nodes by eliminating redundant characters.

Key compression is controlled by an additive integer value representing a bitmask of desired compression types:

• 1: Duplicate key compression. Suppresses repeated key values for alternate keys defined with the WITH DUPLICATES phrase.
• 2: Leading character compression. Suppresses characters at the start of a key that are identical to the leading characters of the preceding key in the index node.
• 4: Trailing space compression. Strips trailing ASCII space characters (x'20') from key values.
• 8: Trailing null compression. Strips trailing binary nulls (x'00'). (Configurable in File Handler configuration files).

These values are combined through simple addition:

• A value of 6 (2 + 4) enables both leading character suppression and trailing space suppression.
• A value of 7 (1 + 2 + 4) enables duplicate suppression, leading character suppression, and trailing space suppression.

Operational Constraint: Trailing space compression (4) and trailing null compression (8) are mutually exclusive.

Scoping Compression per File and Key using $SET

By default, compiler directives specified in compiler options apply to all files defined within the compilation unit. However, file compression settings are determined at file creation time (OPEN OUTPUT) by the last processed directive preceding the file's SELECT statement.

To apply compression selectively to specific files—or even to specific keys within the same indexed file—administrators and developers use inline $SET statements, as shown in the Example of Using Data and Key Compression:

$set callfh"extfh"
$set datacompress"1" 
$set keycompress"6" 
     select transfile 
         assign to "transfile.dat"
         organization is indexed
         record key is t-rec-key. 
$set nokeycompress
$set nodatacompress

     select masterfile 
         assign to "masterfile.dat"
         organization is indexed 
$set keycompress"6"
         record key is m-rec-key 
$set keycompress"7"
         alternate key is m-alt-key-1 with duplicates
         alternate key is m-alt-key-2. 
$set nokeycompress

In this configuration:

1. transfile is created with RLE data compression (DATACOMPRESS"1") and key compression combining leading character and trailing space suppression (KEYCOMPRESS"6").
2. Compression is turned off immediately following the SELECT with $set nokeycompress and $set nodatacompress.
3. In masterfile, data compression is omitted, but the primary record key m-rec-key uses compression 6, while alternate key m-alt-key-1 additionally enables duplicate suppression using compression 7 (KEYCOMPRESS"7").

Operational Prerequisites and Nuances

• Creation-Time Immutability: Compression attributes are stamped directly into the standard file header when the file is created (OPEN OUTPUT). Subsequent programs opening the file in I-O or INPUT mode detect the compression mode automatically from the file header without needing matching DATACOMPRESS or KEYCOMPRESS directives.
• Callable File Handler Dependency: Data compression is implemented exclusively by the Callable File Handler (ExtFH). While indexed files always invoke ExtFH, sequential files accessed by programs that did not create them must be compiled with CALLFH"EXTFH" to ensure the runtime routes reads and writes through the compression-aware handler.
• Selective Scoping Discipline: Always pair $SET DATACOMPRESS and $SET KEYCOMPRESS with corresponding $SET NODATACOMPRESS and $SET NOKEYCOMPRESS directives immediately following the targeted SELECT or key phrase to prevent accidental compression inheritance by subsequent file definitions.

Documentation Takeaway

In Rocket Enterprise Developer 12.0, DATACOMPRESS and KEYCOMPRESS enable fine-grained space and I/O optimization: data compression converts fixed sequential files into variable files where REWRITE requires identical compressed record lengths, while key compression applies additive bitmasks (1 for duplicates, 2 for leading characters, 4 for trailing spaces, and 8 for trailing nulls) that can be targeted per individual key using inline $SET directives.