Document revision date: 19 July 1999

When an ISO 9660-formatted CD-ROM contains information written according to Compaq specifications, affected records may include a DIGITAL System Identifier (DSI) in the associated extended attribute records (XAR). This section describes how DIGITAL System Identifiers are recorded on ISO 9660 media and how a DSI is used to encode OpenVMS formatted information on the media. Figure 1-4 illustrates the DSI and FAT structures in an XAR.

On ISO 9660 media, XARs include fields for specifying a system identifier in byte positions 85 to 116 (see (A), Figure 1-4.) Immediately preceding the DSI structure, the XAR contains three fields containing record information. If the area immediately following the DSI contains OpenVMS file and record information, you should insert nulls in the record information fields immediately preceding the DSI.

• Record format in byte position 79
• Record attributes in byte position 80
• Record length in byte positions 81 to 84

If the DSI file identifier field (DSI$FILE_SYSTEM_IDENTIFIER) contains a 0 and the DSI file version field (DSI$FILE_SYSTEM_VERSION) contains a 1 or a 2, use the area immediately following the DSI to obtain OpenVMS file and record information (See (B), Figure 1-4.)

• If the DSI file version field contains a 1, the area immediately following the DSI contains a binary, hex-encoded, file attributes block that provides file and record information. (See (C), Figure 1-4.)
• If the DSI file version field contains a 2, the area immediately following the DSI contains a ASCII, hex-encoded, byte stream that provides file and record information. (see (D) in Figure 1-4.)

When the DSI file version field contains a 0, the area immediately following the DSI will not contain file and record information. Nevertheless, if the media is mounted for DSI protection, the OpenVMS UIC codes and permission codes for system, owner, group, and world (SOGW) users will be enforced.

Figure 1-4 DSI and FAT Structures in an XAR

1.3 Magnetic Tape Concepts

Characters of data on magnetic tape are measured in bits per inch (bpi). This measurement is called density. A 1600-bpi tape can accommodate 1600 characters of data in 1 inch of recording space. A tape has 9 parallel tracks containing 8 bits and 1 parity bit.

A parity bit is used to check for data integrity using a scheme where each character contains an odd number of marked bits, regardless of its data bit configuration. For example, the alphabetic character (A) has an ASCII bit configuration of 100 0001, where two bits, the most significant and the least significant, are marked. With an odd-parity checking scheme, a marked eighth bit is added to the character so that it appears as 1100 0001. When this character is transmitted to a receiving station, the receiver logic checks to make sure that the character still has an odd number of marked bits. If media distortion corrupts the data resulting in an even number of marked bits, the receiving station asks the sending station to retransmit the data.

Even though a tape may have a density of 1600 bpi, there are not always 1600 characters on every inch of magnetic tape because of the interrecord gap (IRG). The IRG is an interval of blank space between data records that is created automatically when records are written to the tape. After a record operation, this breakpoint allows the tape unit to decelerate, stop if necessary, and then resume working speed before the next record operation.

Each IRG is approximately 0.6 inch in length. Writing an 80-character record at 1600 bpi requires 0.05 inch of space. The IRG, therefore, requires twelve times more space than the data with a resultant waste of storage space.

RMS can reduce the size of this wasted space by using a record blocking technique that groups individual records into a block and places the IRG after the block rather than after each record. (A block on disk is different from a block on tape. On disk, a block is fixed at 512 bytes; on tape, you determine the size of a block.) However, record blocking requires more buffer space for your program, resulting in an increased need for memory. The greater the number of records in a block, the greater the buffer size requirements. You must determine the point at which the benefits of record blocking cease, based on the configuration of your computer system.

Figure 1-5 shows how space can be saved by record blocking. Assume that a 1600-bpi tape contains 10 records not grouped into record blocks. Each record is 160 characters long (0.1 inch at 1600 bpi) with a 0.6-inch IRG after each record; this uses 7 inches of tape. Placing the same 10 records into 1 record block uses only 1.6 inches of tape (1 inch for the data records and 0.6 inch for the IRG).

Figure 1-5 Interrecord Gaps

Record blocking also increases the efficiency of the flow of data into the computer. For example, 10 unblocked records require 10 separate physical transfers, while 10 records placed into a single block require only 1 physical transfer. Moreover, a shorter length of tape is traversed for the same amount of data, thereby reducing operating time.

Like disk data, magnetic tape data is organized into files. When you create a file on tape, RMS writes a set of header labels on the tape immediately preceding the data blocks. These labels contain information such as the user-supplied file name, creation date, and expiration date. Additional labels, called trailer labels, are also written following the file. Trailer labels indicate whether or not a file extends beyond a volume boundary.

To access a file on tape by the file name, the file system searches the tape for the header label set that contains the specified file name.

When the data blocks of a file or related files do not physically fit on one volume (a reel of tape or a tape cartridge), the file is continued on another volume, creating a multivolume tape file that contains a volume set. When a program accesses a volume set, it searches all volumes in the set. For additional information about magnetic tapes, see the OpenVMS System Manager's Manual.

1.3.1 ANSI-Labeled Magnetic Tape

This section describes ANSI magnetic tape labels, data, and record formats supported by OpenVMS operating systems. Note, however, that OpenVMS operating systems also support the ISO standard. For a complete description of these labels, please refer to the ANSI X3.27--1978 or ISO 1001--1979 magnetic tape standard.

1.3.1.1 Logical Format of ANSI Magnetic Tape Volumes

The format of ANSI magnetic tape volumes is based on Level 3 of the ANSI standard for magnetic tape labels and file structure for information interchange. This standard specifies the format, content, and sequence of volume labels, file labels, and file structures. According to this standard, volumes are written and read on 9-track magnetic tape drives only. The contents of labels must conform to prescribed data and record formats. All labels must consist of ASCII "a" characters.

The ANSI magnetic tape format allows you to write binary data in the file sections (see Figure 1-6) of files. However, if you plan to use such files for information interchange across systems, make sure that the recipient system can read the binary data.

1.3.1.2 RMS Magnetic Tape Ancillary Control Process (MTAACP)

The RMS magnetic tape ancillary control process (MTAACP) is the internal operating system software process that interprets the logical format of ANSI magnetic tape volumes. Transparent to your process, the MTAACP process reads, writes, and interprets ANSI labels before passing this information to RMS and $QIO system services. These services, in turn, read, write, and interpret the record format of the data written in the file section.

1.3.1.3 Basic Components of the ANSI Magnetic Tape Format

The format of ANSI magnetic tape consists of the following basic components:

• Beginning-of-tape (BOT) and end-of-tape (EOT) markers
• Tape marks
• File sections
• Volume, header, and trailer labels

Figure 1-6 displays the arrangement and function of these components.

Figure 1-6 Basic Layout of an ANSI Magnetic Tape Volume

Beginning-of-Tape and End-of-Tape Markers

Every volume has beginning-of-tape (BOT) and end-of-tape (EOT) markers. These markers are pieces of photoreflective tape that delimit the writable area on a volume. ANSI magnetic tape standards require that a minimum of 14 feet to a maximum of 18 feet of magnetic tape precede the BOT marker; a minimum of 25 feet to a maximum of 30 feet of magnetic tape, of which 10 feet must be writable, must follow the EOT marker. The EOT marker indicates the start of the end of the writable area of the tape, rather than the physical end of the tape. Therefore, data and labels can be written after the EOT marker.

Tape Marks

Tape marks separate the file labels from the file sections, separate one file from another, and denote the logical end-of-volume. On the basis of the number and relative placement of tape marks written on a volume, OpenVMS systems determine whether a tape mark delimits a label, a file, or a volume.

Tape marks are written both singly and in pairs. Single tape marks separate either a file section from the header and trailer labels or one file from another. When written after a set of header labels, a single tape mark signals the beginning of a file section. When written before a set of trailer labels, a single tape mark indicates the end of a file section. When written after a trailer label set, a single tape mark separates one file from another.

Double tape marks indicate that either an empty file section exists or the logical end-of-volume has been reached. OpenVMS systems create an empty file when a volume is initialized.

Labels

Labels identify, describe, and control access to volumes and their files. The ANSI magnetic tape format supports volume, header, and trailer labels. The volume labels are the first labels written on a volume. They identify the volume and the volume owner and specify access protection. Header and trailer labels are sets of labels that identify, describe, and delimit files. Header labels precede files; trailer labels follow files.

Table 1-6 lists the labels supported by OpenVMS operating systems. All other ANSI magnetic tape labels are ignored on input.

Although each type of label uses a different format to organize its contents, all labels conforming to Version 3 of the ANSI magnetic tape standard must consist of ASCII a characters. Some labels contain reserved fields designed for future system use or future ANSI magnetic tape standardization. Reserved fields also must consist of ASCII a characters; however, OpenVMS systems ignore these characters on input.

Table 1-6 Labels and Components Supported by OpenVMS Systems

Symbol	Meaning
BOT	Beginning-of-tape marker
EOF1	First end-of-file label
EOF2	Second end-of-file label
EOF3	Third end-of-file label
EOF4	Fourth end-of-file label
EOT	End-of-tape marker label
EOV1	First end-of-volume label
EOV2	Second end-of-volume label
EOV3	Third end-of-volume label
EOV4	Fourth end-of-volume label
HDR1	First header label
HDR2	Second header label
HDR3	Third header label
HDR4	Fourth header label
VOL1	First volume label
VOL2	Second volume label
TM	Tape mark
TM TM	Double tape mark indicates an empty file section or the logical end-of-volume

1.3.1.4 Volume and File Configurations

ANSI magnetic tape volumes support four file and volume configurations:

• A single file residing on a single volume
• A single file requiring multiple volumes
• Multiple files residing on a single volume
• Multiple files requiring multiple volumes

All these configurations conform to the following guidelines:

• The file sequence number field allows as many as 9999 file sections for one file. In effect, the file length is unlimited.
• Only one file section of a given file is written on a volume.
• When multiple sections exist for one file, each file section is written to a separate volume in the volume set. The file section numbers of each section are written consecutively in ascending order (section n+1 is written immediately following section n); file sections of other files are not interspersed.

Each of the file and volume configurations is illustrated in the sections that follow.

Single File Residing on a Single Tape Volume

A single file on a single tape volume configuration consists of one file on one volume. The components of the ANSI magnetic tape format for this configuration are illustrated in Figure 1-7.

Figure 1-7 Single File on a Single Volume

Single File Requiring Multiple Tape Volumes

A single-file/multivolume configuration consists of one file that spans two or more volumes in a volume set. Figure 1-8 illustrates the components of the ANSI magnetic tape format for this configuration.

Figure 1-8 Single File on Multiple Tape Volumes

Multiple Files on a Single Tape Volume

A multifile/single-volume configuration consists of two or more files on a single volume. It is the most common file and volume configuration. Figure 1-9 illustrates the components of the ANSI magnetic tape format for this configuration.

Figure 1-9 Multifile/Single-Volume Configuration

Multifile/Multivolume Configuration

A multifile/multivolume configuration consists of two or more files that span two or more volumes in the same volume set. Figure 1-10 illustrates the components of the ANSI magnetic tape format for this configuration.

Figure 1-10 Multifile/Multivolume Configuration

1.3.1.5 Volume Labels

The 80-character volume label (VOL1) is the first label written on an ANSI magnetic tape volume. It defines the label type, name, and owner of the volume. Although there are many fields in a VOL1 label, this section describes only those fields that you can access or that can inhibit access to a volume and its files on OpenVMS systems.

Volume Identifier Field

The volume identifier field is a 6-character field that contains the name of the volume. You specify the volume identifier in the command string when you initialize or mount a volume (see the OpenVMS System Manager's Manual). The volume identifier consists of six ASCII "a" characters. Lowercase characters are not in the "a" set, but if you specify them, OpenVMS systems change them to uppercase. If you specify fewer than six characters, OpenVMS systems pad the field by right-justifying the field with the ASCII space character.

Accessibility Field

The accessibility field is a one-character field that allows an installation to control access to a volume. See the OpenVMS System Manager's Manual for a description of accessibility support.

Implementation Identifier Field

The implementation identifier field contains the identifier of the implementation that creates the magnetic tape. This field controls how certain implementation-specific fields and volume labels are interpreted. The magnetic tape file system's implementation identifier is DECFILE11 A. This field contains the implementation identifier only if a second volume (VOL2) label is written on the magnetic tape. Otherwise, it is filled with ASCII space characters.

Owner Identifier Field

The owner identifier field is available to the user. This field does not affect the checking of a user's access to a volume, except as noted in the OpenVMS System Manager's Manual.

1.3.1.5.2 VOL2 Label

In addition to the first volume (VOL1) label described above, OpenVMS systems provide a second volume (VOL2) label, the volume-owner field.

The volume-owner field contains the OpenVMS protection information that has been written on the magnetic tape. A second volume label is written only if an OpenVMS protection scheme had been specified on either the MOUNT or INITIALIZE command.

The volume-owner field also contains a value that incorporates the user identification code (UIC) with the OpenVMS protection code specified for a volume. By default, OpenVMS systems do not write a UIC to this field, thus allowing all users READ and WRITE access. Note, however, that EXECUTE and DELETE access are not applicable to magnetic tape volumes. Also note that, regardless of the protection code that you specify, both system users and the volume owner always have READ and WRITE access to a volume. The contents of the volume-owner field depends on the OpenVMS protection code that you specify.

1.3.1.6 Header Labels

OpenVMS operating systems support four file-header labels: HDR1, HDR2, HDR3, and HDR4. The HDR3 and HDR4 labels are optional. The following sections describe and illustrate each file-header label.

1.3.1.6.1 HDR1 Label

Every file on a volume has a HDR1 label, which identifies and describes the file by supplying the OpenVMS MTAACP with the following information:

• File identifier
• File-set identifier
• File section number
• File sequence number
• Generation and generation version numbers
• File creation and expiration dates
• Accessibility code
• Implementation identifier

File Identifier Field

The file identifier field contains the first 17 characters of the file name you specify. The remainder of the file name is written into the HDR4 label, provided that this label is allowed. If no HDR4 label is supported, a file name longer than 17 characters will be truncated. You may use either an ANSI magnetic tape file name or an OpenVMS file specification of the following format:

filename.type;version

OpenVMS file specifications are a subset of ANSI magnetic tape file names. However, ANSI magnetic tape file names are valid only for magnetic tape volumes; OpenVMS file specifications are valid for disk and tape volumes. Both types of file specifiers are compatible with compatibility mode.

An OpenVMS file specification consists of a file name, a file type, and an optional version number. Valid file names contain a maximum of 39 characters. Valid file types consist of a period followed by a maximum of 39 characters. The semicolon separates the version number from the file type.

Except for wildcard characters, only the characters A through Z, 0 through 9, and the special characters ampersand (&), hyphen (-), underscore (_), and dollar sign ($) are valid for OpenVMS file names and types. The period and semicolon are the only other valid special characters, and they are always separators.

ANSI magnetic tape file names do not have a file type field. An ANSI magnetic tape file name consists of a 17-character name string, a period, a semicolon, and an optional version number. You can specify a name string consisting of a maximum of 17 ASCII "a" characters, but you must enclose the string in quotation marks (as in, for example, "file name"). When you specify fewer than 17 characters, the string is padded on the right with spaces to the 17-character maximum size. If you specify a file name that has trailing spaces, OpenVMS systems truncate them when the file name is returned. In addition, the space-padded field prevents you from specifying a unique file name that consists of spaces.

Although you can specify longer file names (up to 79 characters), only the first 17 characters of the file name will be used in interchange.

The quotation mark character requires special treatment because it is both the file name delimiter and a valid ASCII "a" character that can itself be embedded in the name string. You must specify two quotation marks for each one that you want the operating system to interpret. The additional quotation mark informs the operating system that one of the quotation marks is part of the name string, rather than a delimiter.

Embedded spaces also are valid characters, but embedded tabs are not. Lowercase characters are not in the ASCII "a" character set, but if you specify them, OpenVMS systems convert them to uppercase characters.

If you do not specify a file type or version number on input, OpenVMS systems supply a period (the default file type) and a semicolon (the default version number). However, the period and semicolon will not be written to this field on the tape.

Although the operating system considers version numbers for ANSI magnetic tape file names and OpenVMS file names to be part of the file name specification, the version number of a file is not written to the file identifier field but is mapped to the generation number and generation version-number fields as described in Generation Number and Generation Version-Number Fields.

Examples below display ANSI magnetic tape file names. The input is the format that you specify. The output shown displays the OpenVMS format returned to your process and the format written to the label. The number sign (#) in the examples indicates a space character. In the last example, an OpenVMS file name is enclosed in quotation marks, like an ANSI magnetic tape file name, on input. However, the operating system returns the file name to the process as an OpenVMS file name, rather than as an ANSI magnetic tape file name. Therefore, when you enclose a valid OpenVMS file name in quotation marks on input, the operating system parses the file name as an OpenVMS file name.

Input "AB2&D""FgHI*k4""#-M";2 "##########" """""""""""""""""""""""""""; "DWDEVOP.DAT" "VMS_LONG_FILENAME.LONG_FILETYPE" Output to User Process "AB2&D""FGHI*K4""#-M";2 "".; """""""""""""""""""""""""""".; DWDEVOP.DAT; VMS_LONG_FILENAME.LONG_FILETYPE Output to HDR1 Label AB2&D"FGHI*K4"#-M ################# """""""""""""#### DWDEVOP.DAT###### VMS_LONG_FILENAME

File-Set Identifier Field

The 6-character file-set identifier field denotes all files that belong to the same volume set. The file-set identifier for any file within a given volume set should always be the same as the file-set identifier of the first file on the first volume that you mount. The file-set identifier is the same as the volume identifier of the first volume that you mount.

File Section Number and File Sequence Number Fields

The file section number is a 4-character field that specifies the number of the file section.

The file sequence number is a 4-character field that specifies the number of the file in a file set.

Generation Number and Generation Version-Number Fields

The generation number (a decimal number from 0001 to 9999) and generation version-number (a 2-digit decimal number) fields store the file version number specified on input and written by the system on output. The operating system does not increment the version number of a file, even when the version of the specified file already exists on the volume. Therefore, if the file that you specify has the same file name and version number as an existing file, you will have at least two files with the same version number on the same volume set.

On input, OpenVMS systems compute the version number by using this calculation:

	privacy and legal statement
4506PRO_002.HTML