Defining Compressed Records in COBOL Application Programs

CA Compress/2 › Defining Compressed Records in COBOL Application Programs

Defining Compressed Records in COBOL Application Programs

Compressed records are variable-length records. This fact requires special attention in COBOL application programs, because COBOL does not support variable length data conveniently. For this reason, it is especially advisable with COBOL to use the CA Compress Transparency or SUBSYS and not CA Compress/2.

Variable-length records are defined by the OCCURS DEPENDING ON data-name clause, where the element defined by data-name contains a value which indicates the actual number of characters in the variable- length record. The SHRINK subroutine (but not SHRINKZ or SHRINKS, which do not use RDL) generates this value and places it in the compressed record in response to a field type L record definition, but COBOL does not recognize this value until it is explicitly placed in data-name by a COBOL statement. Field type L does not support records larger than 32K.

The following procedure is recommended for altering a COBOL application program to process a compressed file.

FOR SHRINK, use the field type L RDL specification as the first, or only, RDL specification when the file is compressed. This specification causes CA Compress/2 to store the actual data length of each variable-length compressed record as a two-byte binary field at the beginning of each compressed record. For SHRINKZ, define a field in front of the compressed data and set it to the length of the compressed data that follows. In both cases, remember to move it to the OCCURS DEPENDING ON variable—to itself if necessary—to let COBOL know that the value has changed.
Move the definition(s) of the uncompressed data records from the FILE SECTION to the WORKING-STORAGE SECTION.
Change RECORDING MODE from F to V or S, as necessary.
Supply the following as the data record in the FILE SECTION for the compressed file (update the FD to refer to this record definition as DATA RECORD):
```
01 SHRUNK-RECORD.
03 LENGTH PICTURE 9(4) USAGE COMPUTATIONAL.
03 SHRUNK-DATA PICTURE X OCCURS n TIMES DEPENDING ON LENGTH.
```
Substitute the maximum record length for the value n.
Move the maximum value to LENGTH before the READ to ensure that SHRUNK-RECORD is long enough to hold all the bytes that are read.
Code a call to EXPAND, EXPANDS, SHRKHCX, or EXPANDZ, as appropriate, and insert it immediately after the READ for the file in question. Code SHRUNK-RECORD as the CRA parameter in the call to the expansion routine. Code the data record name of the record definition moved to the WORKING-STORAGE SECTION as the URA parameter in the call to the expansion routine.
If issuing calls to the SHRINK subroutine, provide the following compressed record area in the WORKING-STORAGE SECTION (not the FILE SECTION):
```
01 COMPRESS-AREA.
03 RDW PICTURE 9(5) USAGE COMPUTATIONAL.
03 SHRUNK-RECORD-OUT.
05 LENGTH-OUT PICTURE 9(4) USAGE COMPUTATIONAL.
05 SHRUNK-DATA-OUT PICTURE X OCCURS n TIMES
   DEPENDING ON LENGTH-OUT.
```
The user must substitute the value of the OUTFILE LRECL increased by 290 for the value n, and must explicitly move this value to LENGTH-OUT before the SHRINK call to ensure that COMPRESS-AREA is long enough. Code COMPRESS-AREA as the second (CRA) parameter of the SHRINK subroutine call. If the output record definition in the FILE SECTION is coded:
```
01 UPDATED-SHRUNK-RECORD.
03 UPDATED-LENGTH PICTURE 9(4) USAGE COMPUTATIONAL.
03 UPDATED-SHRUNK-DATA PICTURE X OCCURS n TIMES
	   DEPENDI	NG ON UPDATED-LENGTH.
```
The updated compressed record is written as follows:

MOVE LENGTH-OUT TO UPDATED-LENGTH.
WRITE UPDATED-SHRUNK-RECORD FROM SHRUNK-RECORD-OUT.
Compile using the NOTRUNC option.