![[Compaq]](../../images/hp.gif)
![[Go to the documentation home page]](../../images/buttons/hp_bn_site_home.gif)
![[How to order documentation]](../../images/buttons/hp_bn_order_docs.gif)
![[Help on this site]](../../images/buttons/hp_bn_site_help.gif)
![[How to contact us]](../../images/buttons/hp_bn_comments.gif)
![[OpenVMS documentation]](../../images/hp_ovmsdoc_sec_head.gif)
| Document revision date: 15 July 2002 | |
|
|
|
|
|
|
| Previous | Contents | Index |
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. The following three fields contain record information:
If the DSI file identifier field (DSI$FILE_SYSTEM_IDENTIFIER) contains a 0 and the DSI file version field (DSI$FILE_SYSTEM_VERSION) contains either 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 an 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
This section describes magnetic tape concepts.
Data records are organized on magnetic tape in the order in which they
are entered; that is, sequentially.
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:
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 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 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.
| 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 |
ANSI magnetic tape volumes support four file and volume configurations:
All these configurations conform to the following guidelines:
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 sections that follow describe the first volume (VOL1) and second
volume (VOL2) labels.
1.3.1.5.1 VOL1 Label
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.
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.
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.
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:
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
|
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:
| Previous | Next | Contents | Index |
|
|
| privacy and legal statement | ||
| 4506PRO_002.HTML | ||