Document revision date: 30 March 2001

Extended File Specifications allows files with Windows 95 style or Windows NT style file names and attributes to reside on, and to be managed from, OpenVMS Alpha systems. Extended File Specifications support can also be selected on a per-volume basis.

Traditional and Extended File Names

In an Extended File Specifications environment, you can select either of the following naming styles for file specifications:

• Traditional file names are allowed on both ODS-2 and ODS-5 volumes.
• Extended file names are allowed on ODS-5, but not on ODS-2 volumes.

For detailed definitions of traditional and extended file names as well as other introductory information about Extended File Specifications, refer to the OpenVMS Guide to Extended File Specifications.

The following sections describe the current levels of disk, mixed-version, mixed-architecture, and network support for Extended File Specifications on OpenVMS systems.

9.1.2.1 System and User Disk Support

Restrictions and suggestions for using Extended File Specifications on your system are as follows:

• You can mount an ODS-5 volume only on an OpenVMS VAX or an Alpha Version 7.2 or later system. Most applications can access only traditionally named files on a VAX system.
• Compaq does not support creating the system disk as (or changing it to) an ODS-5 volume.

Users on OpenVMS Version 7.2 and later systems can take advantage of Extended File Specifications capabilities. In contrast, systems running prior versions of OpenVMS cannot mount ODS-5 volumes or correctly handle extended file names.

The following sections describe support on OpenVMS Version 7.2 and on prior versions of OpenVMS in a mixed-version cluster.

Users on OpenVMS Version 7.2 Systems

Users on OpenVMS Version 7.2 systems can continue to access pre-Version 7.2 files and directories. For example, they can perform all of the following actions:

• Create and access deep directory structures on ODS-2 volumes.
• Read a BACKUP save set created on an earlier version of OpenVMS.
• Use DECnet to copy a file with an ODS-5 name to a file with an ODS-2 name on a system running an earlier version of OpenVMS.

Users on Systems with Versions Prior to OpenVMS 7.2

On mixed-version clusters, some restrictions exist. Users on a version of OpenVMS prior to Version 7.2 have these limitations:

• Cannot access any files on an ODS-5 volume. This is true regardless of whether the volume is connected physically on a CI or SCSI, or by an MSCP or QIO server.
• Cannot successfully create or restore an ODS-5 image save set. However, these users can successfully restore ODS-2-compliant file names from an ODS-5 save set.

All Extended File Specifications capabilities are available on OpenVMS Alpha systems. Nearly all the current ODS-2 disk and file management functions remain the same on both VAX and Alpha Version 7.2 systems; however, extended file naming and parsing are not available on VAX systems.

The following sections describe support on OpenVMS VAX and Alpha systems in a mixed-architecture cluster.

Limited Extended File Specifications Capabilities on VAX Systems

In mixed-architecture OpenVMS Version 7.2 clusters, the following limited Extended File Specifications capabilities are available on OpenVMS VAX systems:

• Ability to mount and manage an ODS-5 disk
• Ability to write and manage ODS-2-compliant files on an ODS-5 disk

BACKUP Limitations

On an OpenVMS VAX system, users cannot successfully create or restore an ODS-5 image save set. However, these users can successfully restore ODS-2-compliant file names from an ODS-5 save set.

Users can also perform a disk-to-disk copy from ODS-5 to ODS-2 as long as they do not specify /IMAGE.

For more information, refer to the OpenVMS Guide to Extended File Specifications.

9.1.2.4 Network Support

For OpenVMS Version 7.2 and later, the length of a file specification that can be sent over the network using DECnet is shorter than the maximum size of a file specification without the use of a network.

9.1.2.5 Enabling Extended File Specifications Features

To enable Extended File Specifications On-Disk Structure features for a volume on an OpenVMS Alpha system, you must perform one of the following actions:

Task	Reference
Initialize a new volume as ODS-5	Section 9.3.3
Convert an existing volume from ODS-2 to ODS-5	Section 9.5.5.1

Creating ODS-5 volumes allows you to take advantage of extended file names for Compaq Advanced Server for OpenVMS clients; you can see and manage these names from OpenVMS Alpha systems.

The file storage system for magnetic tapes is based on the standard magnetic tape structure as defined by ISO 1001--1986, which is compatible with several national standards such as ANSI X3.27--1987.

For more information about tape concepts, refer to the Guide to OpenVMS File Applications.

Table 9-6 defines terms that apply to magnetic tapes.

Table 9-6 Terms Related to Magnetic Tapes

Term	Definition
Block	On magnetic tape, the size of a block is determined by the user. On ODS disks, a block is fixed at a size of 512 bytes.
bpi	Bits per inch; measure used for characters of data on tape on OpenVMS systems. Also called density.
IRG	Interrecord gap; interval of space between blocks.
Record blocking	Grouping of individual records into a block, thereby reducing wasted space.
Sequential	Organization of magnetic tape data; that is, data is organized in the order in which it is written to the tape.
Magnetic Tape Ancillary Control Process (MTACP)	Internal software process that interprets the logical format of standard labeled volumes.
Beginning-of-tape (BOT) marker and end-of-tape (EOT) marker	Pieces of photoreflective tape that appear on every volume to delimit the writable area on the volume. ANSI 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 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.
Data record storage	Within tape files, data records are stored in variable-size data blocks. Each block contains one or more records. RMS provides management of records.
Header labels	Set of labels that the tape file system writes on the tape immediately preceding the data blocks when you create a file on tape. These labels contain information such as the user-supplied file name, creation date, and expiration date. To access a file on magnetic tape by the file name, the file system searches the tape for the header label set that contains the specified file name.
Trailer labels	Set of labels that the tape file system writes on the tape following the file.
Multivolume file	Additional volume on which a file is continued when the data blocks of a file or related files do not physically fit on one volume (a reel of magnetic tape).
Volume set	The volumes on which a set of files is recorded.

9.1.3.1 Record Blocking

Figure 9-2 shows how record blocking can save space.

Figure 9-2 Record Blocking

Assume that a 1600-bits-per-inch magnetic tape contains 10 records that are not grouped into a block. Each record is 160 characters long (0.1 inch at 1600 bits per inch) with a 0.6-inch IRG after each record, which uses 7 inches of tape. However, placing the same 10 records into one block uses only 1.6 inches of tape (1 inch for the data records and 0.6 inch for the IRG).

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 in a single block require only one physical transfer. Moreover, a shorter length of magnetic tape is traversed for the same amount of data; thus, the operation is completed in less time.

However, record blocking requires more buffer space to be allocated for your program. 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. Base this determination on the configuration of your computer system and your environment.

9.1.3.2 Multiple Tape Densities (Alpha Only)

In versions of OpenVMS Alpha prior to Version 7.2, the range of densities that users were able to set for magnetic tape devices was limited. On OpenVMS Version 7.2 and later Alpha systems, that range includes any density that a specific tape drive supports. Because of this enhancement, exchanging tapes among tape drives with different default settings for density is much easier.

You can set densities using the following DCL commands:

• $ INITIALIZE
• $ SET MAGTAPE (for tapes only)

Refer to the OpenVMS DCL Dictionary for details about using the /DENSITY qualifier with these DCL commands.

You can also set densities using the following system management utilities:

• $ MOUNT (with /FOREIGN qualifier for mounted tapes)
• $ BACKUP

Refer to the OpenVMS System Management Utilities Reference Manual for details about using the /DENSITY qualifier with these utilities. Also refer to Chapter 11 for details about using the /DENSITY qualifier with BACKUP.

Example

$ INITIALIZE/DENSITY=tk85 MKA500: TEST
      

The command in this example initializes the media in the MKA500: drive to tk85 density with a label of TEST.

Densities Supported

The following densities are valid in the command strings for DCL commands and system management utilities: 800, 1600, 6250, DAT, 833, DDS1, DDS2, DDS3, DDS4, TK50, TK70, TK85, TK86, TK87, TK88, TK89, 8200, 8500, 3480, 3490E, AIC, AIT, and DEFAULT.

Usage Notes

You cannot use multiple tape densities on one piece of media. In other words, one density applies to one piece of media. If you do not specify a density, the default density is used; the default is the highest density a particular drive supports.

Density changes can occur only at beginning-of-tape (BOT). Once media is initialized to a density, the media remains at that density until it is reinitialized to a different density.

If a density is not supported on a particular device, depending on the drive, the density field either remains the same or takes the default. If a drive does not support the density you select, the system displays an invalid density error. Some drives do not report the error and simply ignore your selection, leaving the media at the previous density.

When media is set to a specific density, the "density" field displayed when you enter $ SHOW DEVICE/FULL MKA300: , for example, displays the corresponding ASCII string for density.

Magtape JENSO3$MKA300:, device type TZ87, is online, file-oriented device, error logging is enabled, controller supports compaction (compaction, disabled), device supports fastskip. Error count 0 Operations completed 0 Owner process "" Owner UIC [SYSTEM] Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G:R,W Reference count 0 Default buffer size 2048 Density TK85 Format Normal-11 Volume status: no-unload on dismount, position lost, odd parity.

9.1.4 Public and Private Disk Volumes

A volume is one or more units of storage media that you can mount on a device. The volume is the largest logical unit of disk file structure.

This section explains the concepts of public and private volumes.

9.1.4.1 Public Disk Volumes

A public volume is a file-structured disk volume that can contain both private and public files. Public volumes can be either of the following ones:

Type of Volume	Description
System volumes	Available to all the users on a system
Group volumes	Available to all the users in a group

As long as file protections permit it, all users have access to public volumes and to the files on them.

One way to permit users to create and store files on a public volume is to create a default directory on the public volume for each authorized user. You control access to public files and volumes by the protection codes that you establish.

A user is free to create, write, and manipulate files on a public volume only under the following conditions:

• Volume and file protection allow access, or you have privileges that allow you to access the files.
• The user has appropriate access to a directory on the volume.
• Disk quota permits usage.

The following sections contain guidelines for setting up and maintaining public files and volumes.

Planning Public Volumes

You must balance users' space needs with the system's available mass storage resources. These determinations depend, in part, on whether you have relatively small or large mass storage capability. A comparison of the two follows.

Configuration	Characteristics
Small mass storage	Both system files and user files are on the same public volume. You might want to set disk quotas to ensure that user files do not exhaust the free space on the disk volume.
Large mass storage	Keep all system files on one disk volume (known as a system disk or a system volume), and keep all user files on separate volumes. The system disk is kept active reading system images, paging and swapping, spooling files, maintaining system logs, and so forth.

The most common arrangement is to have one public volume with system files and the directories of privileged users, and other public volumes dedicated to user directories, databases, and applications required by your site.

Whichever arrangement you select, plan each public volume and monitor disk performance once the system is running:

• Be sure the system disk has enough space for the operating system to boot and accept updates.
• Once the system is running, use the Monitor utility (MONITOR) to analyze disk use to determine whether disk I/O is balanced across the configuration. Section 20.8 discusses this utility in detail.

You can often move system files off the system disk and use search lists or logical names to access them. See Section 17.8 for more information.

In large configurations, you can place secondary paging and swapping files on other devices to balance disk load. See Section 16.16 for more information. The OpenVMS Performance Management provides detailed information about redistributing system files and achieving a balanced disk load.

9.1.4.2 Private Disk Volumes

A private volume is a file-structured volume that contains only private files.

Under some circumstances, users might want to perform their work on a device that unauthorized users cannot access. By creating a private volume and mounting it on a device allocated exclusively to a user's process, you ensure that users can perform their work without fear of interference from others.

Users can often prepare and manipulate their own private volumes. They might, however, need your assistance if the computer and its peripheral devices are off limits to or remotely located from them. Users requiring assistance can use the operator communication manager (OPCOM) to communicate with an operator. See Section 9.5.3 for instructions on answering users' requests for assistance.

9.2 Allocating and Deallocating Drives

This section explains how to allocate and deallocate drives. The only situation in which the ALLOCATE command is required, however, is when you must retain control of the same volume across dismounts. An example of this is when you alternate between mounting a tape using the /FOREIGN and /NOFOREIGN qualifiers.

9.2.1 Allocating Drives

Use the DCL command ALLOCATE to logically assign a disk drive or a tape drive to your process. You might do this if you suspect an error and want to reserve a disk while you repair the error.

The ALLOCATE command allocates only one device to a process. To allocate several devices, you must use multiple commands.

How to Perform This Task

Enter the ALLOCATE command using the following format:

ALLOCATE device-name[:] [logical-name]

where:

device-name	Specifies the drive on which the volume will be loaded. The device name can be a physical, generic, or logical name.
logical-name	Specifies an optional logical name to be associated with the specified disk or tape drive.

Examples

1. $ ALLOCATE DUA2: %DCL-I-ALLOC, _MARS$DUA2: allocated

   
   In this example, the ALLOCATE command specifies a physical device named DUA2:, which requests the allocation of a specific RK10 disk drive; that is, unit 2 on controller A. The response from the ALLOCATE command indicates that the device was successfully allocated.

2. $ ALLOCATE/GENERIC RA90 MYDISK

   
   This example shows how to use the /GENERIC qualifier with the ALLOCATE command to allocate a particular type of device. In this case, the system allocates the first available RA90 drive to your process.

For further discussion of the /GENERIC qualifier and other qualifiers that you can use with the ALLOCATE command, refer to the OpenVMS DCL Dictionary. The OpenVMS User's Manual contains additional examples of the ALLOCATE command.

9.2.2 Deallocating Drives

Allocating a device reserves that device for exclusive use by your process. The device remains allocated to your process until you explicitly deallocate it or until you log out.

Logging out of a process from which drives have been allocated automatically deallocates all explicitly and implicitly allocated drives; therefore, explicitly deallocating a disk or a tape drive that has been allocated to your process is not necessary. Compaq, however, recommends that you use the DEALLOCATE command (or a command procedure containing this command) explicitly to deallocate all the drives you allocated with the ALLOCATE command.

How to Perform This Task

Use the DCL command DEALLOCATE to explicitly deallocate a disk drive or tape drive that has been allocated to your process. A complement to the ALLOCATE command, the DEALLOCATE command logically disconnects a drive from your process and returns it to the pool of devices.

Enter the DEALLOCATE command using the following format:

DEALLOCATE device-name[:]

where:

device-name

Specifies the drive on which the volume will be loaded. The device name can be a physical, generic, or logical name.

Example

The following example shows how to explicitly deallocate a tape drive or a disk drive:

$ DEALLOCATE MUA1:

In this example, the DEALLOCATE command logically disconnects tape drive MUA1: from your process. The system returns you to DCL level.

	privacy and legal statement
6017PRO_031.HTML