ACUCOBOL-GT treats sequential files in one of two ways. One form is called binary sequential; the other form is called line sequential. Note that RECORD SEQUENTIAL is synonymous with BINARY SEQUENTIAL.
Binary sequential files are designed to contain non-ASCII information and are easy to move to foreign systems. A binary sequential file consists of either fixed-length or variable-length records grouped together into blocks.
Variable-length binary sequential records occupy only as much disk space as necessary. If the maximum record size is equal to or less than 65,535 bytes, two bytes indicating record size (VLI) are placed in front of each variable-length record when it is written to disk. If the record size is larger than 65,535 bytes, four bytes are placed in front of each variable-length record. This two- or four-byte field is not specified in your COBOL program, and non-COBOL programs that access the records need to be aware of the extra bytes.
All I/O on the physical device is done using the block size, except for the last block. Only that portion of the last block that contains records is read. The default block size is one record. You can change block size with the BLOCK CONTAINS clause.
On VMS systems, binary sequential files are sequential RMS files with fixed-length or variable-length records.
Line sequential files contain variable-sized records. These files are designed to be printed and to be used with other programs, such as editors. The exact form of these files depends on the host system, and thus they should not generally be treated as portable files. On many machines, these files consist of variable-length lines delimited by carriage-control characters. These files should contain only USAGE DISPLAY data so as not to inadvertently introduce stray carriage-control characters.
On Windows systems, a line sequential file contains each data record followed by a carriage-return/line-feed pair. On UNIX systems, these files use just a line feed as the delimiter. On VMS systems, a line sequential file is a sequential RMS file with variable-length records.
ACUCOBOL-GT performs all of its I/O on line sequential files according to the following rules. If the file is blocked (i.e., it has a BLOCK CONTAINS clause), then all I/O is done by blocks. Otherwise, all output is done one record at a time. Input, on the other hand, is internally blocked by runcbl. This provides an efficient interface while still providing line-by-line control over a print device (which may be needed to do form alignment, for example).
Line sequential files further break into two types, print files and variable-length files. Print files are similar to variable-length files except that different line-delimiting characters are used. These characters are chosen so that the resulting file will print correctly. Print files may not be opened for INPUT or I-O. Print files are designed to be efficiently printed.
When a line sequential file is read, the default behavior is that any carriage-return, line-feed, or form-feed characters in the record are removed before the record is made available to the program. See Runtime Configuration for information on changing this default behavior.
Some line sequential files have automatic blank stripping. This causes records written to the file to have any trailing spaces in the record removed before it is written to the file. All print files have automatic blank stripping. You can specify blank stripping for other line sequential files by choosing one of the following device types in the file's ASSIGN phrase: CARD-PUNCH, CARD-READER, CASSETTE, INPUT, INPUT-OUTPUT, MAGNETIC-TAPE or OUTPUT. See the ACUCOBOL-GT Reference Manual for details on the ASSIGN phrase.
When reading from a variable-length sequential file, runcbl treats short records in one of two ways. If blank-stripping is specified for the file, then the short records are padded with spaces to fill out to the maximum record size. If blank-stripping is not specified, then the trailing portion of the record is left unchanged (from the most recent contents of the record area).
The runtime system allows a sequential file to be opened for input when the user does not have write-access to the file.