Every file on OpenVMS (even a terminal!) is an RMS file of some kind. Although you can side-step RMS in your program (not recommended), the files you read and write will still be RMS files one way or another.
For disk files, records are typically allowed to span block boundaries. That is, a record is not required to either begin or end at the beginning of a disk block. The exception is, of course, files whose records are 512-byte fixed-length. These records, by definition, always begin and end at disk block boundaries, because each disk block contains 512 bytes of data.
File Formats
RMS provides for files of the following types (formats)
having either fixed or variable-length records:
Sequential files include (but are not limited to) all forms of text files, most forms of object files, executable images, library files, compressed archives, uncompressed archives and all forms of "stream" files. See the discussion of Record Formats for a description of "stream" format files.
Indexed (or "ISAM") files include the index structure as part of the file. Index buckets and data buckets can be interspersed within the file, entirely transparent to the programs which manipulate the data. RMS assumes full responsibility for (the majority) of the tasks involved in maintaining the data and indices. The program you write does not need to be concerned with this.
Indexed files may have either fixed or variable-length records. For variable-length records, the minimum length of a record is determined by the indexed key attributes.
Indexed files have the added virtue of allowing the data within the records to be compressed, thus reducing the disk space required to contain the records. There is a performance price to be paid for this, however. Indices may also be compressed.
Indexed files may have from 1 to 255 keys. Key fields may be contiguous or segmented (non-contiguous). The primary key (key 0) may allow duplicates but may never allow changes. All alternate keys may allow both duplicates and changes. Indexed key fields may be character strings, binary integer data types or packed decimal. (Note, however, that DCL's READ command supports only character string index keys.)
Indexed files may be read sequentially or randomly. Indexed keys may be defined with either an ascending or descending collating sequence.
When records are deleted from indexed files, the buckets occupied are simply marked as deleted, and are not immediately made available for re-use. To make deleted buckets available for re-use (useful mostly for files having fixed-length records), use the CONVERT/RECLAIM command. (See the OpenVMS DCL Dictionary or the on-line HELP for information on this command.)
Relative files are a sort of "half step" between indexed and non-indexed files. Most commonly, these are found as having fixed-length records. Relative files can be accessed sequentially, but also allow for random access by "relative" record number (hence, the name). By contrast, sequential files can only be accessed sequentially (although an update of the "current" record is allowed in some cases).
Some applications keep their own indices for relative files in separate index files. These index files are usually also relative files. Each index contains the key value and the relative record number in the master file to which the index record is linked. There is no theoretical limit to the number of index keys which can be set up using this approach.
Typically, you find this and other uses of relative files in DIBOL applications on VMS, RSTS/E and/or RT-11, sometimes even on RSX. Of these operating systems, only RT-11 does not (usually) include RMS. You may also find this in cases where DIBOL applications have been ported to a non-DEC operating system, such as DOS or UN*X using a DIBOL emulator. Such operating systems also lack RMS, as a rule.
Fixed record length files contain only the data in the records. Executable image (.EXE) files and library (.%LB) files are examples of sequential files having 512-byte fixed-length records. Compressed .ZIP archives, "tar" archives and GnuZIP archives are also usually found as sequential files having 512-byte fixed-length records (but may also be found as having a record format of STREAM_LF).
With the exception of "stream" files, the records in variable record length files include a two-byte (signed) length attribute at the beginning of each record followed by the data (32,767 bytes maximum, including the two-byte length attribute). When returned to your program by RMS, the length attribute is stripped off and only the data is passed. You can then call system services or use a 3GL language element, such as DEC BASIC's RECOUNT built-in function, to retrieve the length of the record most recently read from a file.
"Stream" files include STREAM, STREAM_CR and STREAM_LF format files. STREAM files contain data where records are delimited by <CR><LF> (carriage-return, linefeed) pairs (DOS format). STREAM_CR files contain data where records are delimited by a <CR> (carriage-return). STREAM_LF files contain data where records are delimited by a <LF> (linefeed) (UN*X format).
In "stream" files, the data in the records are NOT preceded by a length attribute. When returned to your program by RMS, the record delimiting character(s) is(are) stripped off and only the data is passed.
RMS file characteristics include "record attributes" which have to do with "carriage" control and are meaningful only in certain contexts. When reading or writing data, however, your program neither receives extraneous characters from the data file nor outputs extraneous characters to the data file, regardless of the file's record attributes.
Typically, these record attributes apply to situations where records from a file are being displayed on a terminal-class or printer-class device, such as a video display terminal or a printer. Record attributes instruct the terminal (or printer) driver (or even the program itself!) to include (or not include) carriage control characters in the output stream at the end of each record displayed or printed. This is sometimes called "implied carriage control" because the carriage control characters are not actually part of the data in the file, but are "implied" to be needed (or not needed) by the presence (or absence) of the associated record attribute.
Confusion frequently arises when a file whose record attributes are "carriage return carriage control" also contain carriage control characters such as <CR> (carriage return, ASCII 13) or <LF> (linefeed, ASCII 10). In such cases, double spacing is frequently seen when the file is printed. To resolve this, either avoid "embedded carriage control" or create the output file to have no record attributes.
Including <FF> (form feed, ASCII 12) characters in reports and listings is entirely valid and normal, and is the preferred way to begin a new page, rather than simply spacing down using blank lines to begin a new page.
Including <CR> (carriage return, ASCII 13) characters in reports and listings is entirely valid, since this is sometimes used to achieve "over-striking" on impact printers. This is done for "bolding", underscoring and for other reasons.
Another method used to achieve "over-striking" on impact printers is to include a <BS> (back-space, ASCII 8) character after the character to be over-struck, followed by the character with which it will be overstruck, such as the same character (to achieve "bold" print) or an underscore, or some other character.
Including <TAB> (horizontal tab, ASCII 9) characters in reports and listings is entirely valid, but may produce unexpected results if the terminal or printer characteristics are not set correctly, either in VMS or on the terminal or printer itself.
Including <VT> (vertical tab, ASCII 11) characters can also produce unpredictable results if the terminal or printer is not set up correctly to handle them. The VMS terminal and printer drivers usually pass this character transparently.
Home Page Operating Systems Products Specialties Freeware
FreeVMS Page Bulletin Board Contact Us About Us
Tradenames, trademarks, service marks, etc. appearing on this page are the property of their registered owners.
"DJE Systems" is a service mark of David J. Dachtera, doing business
as DJE Systems.
This page Copyright ©1998,1999 by David J. Dachtera, All Rights
Reserved.