HP OpenVMS systems
Alpha OpenVMS Version 7.2 and greater and OpenVMS I64 implement Extended File Specifications, which consists of two major components:
Taken together, these components provide much greater flexibility for OpenVMS Alpha systems (using Advanced Server for OpenVMS formerly known as PATHWORKS for OpenVMS), to store, manage, serve, and access files that have names similar to those in a Windows environment. Advanced Server support for OpenVMS I64 is planned for a subsequent release.
This chapter provides a brief overview of the benefits, features, and support for Extended File Specifications, as well as changes in OpenVMS behavior that occur under Extended File Specifications.
For more information about extended file specifications, see the
Guide to OpenVMS File Applications, and the HP OpenVMS System Manager's Manual.
29.1 Benefits of Extended File Specifications
The deep directories and extended file names supported by Extended File Specifications provide the following benefits:
Extended File Specifications consists of two main features, the ODS-5
volume structure, and support for deep directories. These features are
described in the sections that follow.
29.2.1 ODS-5 Volume Structure
OpenVMS implements On-Disk Structure Level 5 (ODS-5). This structure provides the basis for creating and storing files with extended file names. You can choose whether or not to convert a volume to ODS-5 on your OpenVMS Alpha and OpenVMS I64 systems.
The ODS-5 volume structure allows the following features:
These features are described in the sections that follow.
220.127.116.11 Long File Names
On an ODS-5 volume, the name of a file (excluding the version number)
can be up to 236 8-bit or 118 16-bit characters long. Complete file
specifications longer than 255 bytes are abbreviated by RMS when
presented to unmodified applications.
18.104.22.168 More Characters Legal Within File Names
ISO LATIN-1 and Unicode (UCS-2) Character Sets
The ISO Latin-1 Multinational character set is a superset of the traditional ASCII character set used by versions of OpenVMS previous to Version 7.2. In extended file specifications, all characters from the 8-bit ISO Latin-1 Multinational character set are valid in file specifications as of OpenVMS Version 8.2, except the following:
Question mark (?)
To unambiguously enter or display certain special characters in an
ODS-5 compliant file specification, such as a space, you must precede
the character with a
22.214.171.124 Preservation of Case
On ODS-5 disks on Alpha and I64 systems, the Extended File Specifications support preserving case (as in uppercase and lowercase letters). If a file is created with lowercase letters from program control, the name, as stored on disk, is lowercase.
From the DCL command interface, file names that are entered at the command prompt with lowercase letters will be translated by default to uppercase before they are passed to RMS. Case may be preserved from the DCL command interface by using the DCL command SET PROCESS/PARSE_STYLE=EXTENDED (also see the SYS$SET_PROCESS_PROPERTIESW system service).
File look-ups, however, are case-blind. For example, the filename "File.Txt" (as stored on an ODS-5 disk) could be accessed with a reference to "FILE.TXT" or "file.txt".
An option may be set for file look-ups at either the process or file level to request RMS to either ignore or notice the case sensitivity of file names on ODS-5 disks.
At the process level, the user may request RMS to ignore case by using SET PROCESS/CASE_LOOKUP=BLIND. If a file on an ODS-5 disk already exists whose name matches that of a file being created except for its case, the new file will be created with the same case as the existing file (rather than with the case as entered). This is the default behavior. In contrast, the user may request RMS to notice case by using SET PROCESS/CASE_LOOKUP=SENSITIVE (also see the SYS$SET_PROCESS_PROPERTIESW system service). If the SENSITIVE option is in effect and the user creates more than one file on an ODS-5 disk with the same name differing only in case, each file is treated as a new file.
At the file level, the NAML$V_CASE_LOOKUP flag can be used to instruct RMS to ignore or notice case for a file on an ODS-5 disk (see the NAM$L_INPUT_ FLAGS field in the NAML structure in the OpenVMS Record Management Utilities Reference Manual. NAML$C_CASE_BLIND is set to tell RMS to ignore case or NAML$C_CASE_LOOKUP_SENSITIVE to notice case when creating, deleting or searching for a file on an ODS-5 disk. If the NAML structure is not used or this flag is zero, the current process setting for CASE_LOOKUP is used.
The SET PROCESS/PARSE_STYLE qualifier is independent of the /CASE_
LOOKUP qualifier. If the creation, deletion, or search of files on an
ODS-5 disk is being done using the DCL command interface and case is
relevant, /PARSE_STYLE=EXTENDED must be used to inform the DCL
interface to preserve the case specified in the DCL command. The
/CASE_LOOKUP qualifier instructs RMS whether to ignore or notice the
case (either preserved or not).
29.2.2 Deep Directory Structures
For example, a user can create the following deeply nested directory:
$ CREATE/DIRECTORY [.a.b.c.d.e.f.g.h.i.j.k.l.m]
A user can create the following directory with a long name on an ODS-5 volume:
$ CREATE/DIRECTORY [.AVeryLongDirectoryNameWhichHasNothingToDoWithAnythingInParticular]
Complete file specifications longer than 255 bytes are abbreviated by
RMS when presented to unmodified applications.
126.96.36.199 Directory Naming Syntax
On an ODS-5 volume, directory names conform to most of the same
conventions as file names when using the ISO Latin-1
character set. Periods and special characters can be present in the
directory name, but in some cases, they must be preceded by a
circumflex (^) in order to be recognized as literal characters.
29.3 Considerations Before Enabling ODS-5 Volumes
Once ODS-5 volumes are enabled, some of the new capabilities can potentially impact certain applications or layered products, as well as some areas of system management. The new syntax for file names that is allowed on ODS-5 volumes cannot be fully utilized on ODS-2 volumes. Because pre-Version 7.2 Alpha systems cannot access ODS-5 volumes, and Open VMS Version 7.2 VAX systems have limited ODS-5 functionality, you must be careful where and how you enable ODS-5 volumes in mixed-version and mixed-architecture OpenVMS Clusters.
The following sections comprise a summary of how enabling ODS-5 volumes
can impact system management, users, and applications.
29.3.1 Considerations for System Management
RMS access to deep directories and extended file names is available only on ODS-5 volumes mounted on OpenVMS I64 and OpenVMS Alpha V7.2 and greater systems. HP recommends that ODS-5 volumes be enabled only on a homogeneous OpenVMS I64 or OpenVMS Alpha V7.2 and greater Cluster.
If ODS-5 is enabled in a mixed-version or mixed-architecture OpenVMS Cluster, the system manager must follow special procedures and be aware of specific restrictions on mixed-version and mixed-architecture OpenVMS Clusters with ODS-5 volumes enabled:
Section 29.3.2 describes in greater detail the limitations of ODS-5 support for users in a mixed-version or mixed-architecture OpenVMS Cluster.
Most unprivileged applications will work with most extended file names,
but some may need modifications to work with all extended file names.
Privileged applications that use physical or logical I/O to disk and
applications that have a specific need to access ODS-5 file names or
volumes may require modifications and should be analyzed. See the
website http://h71000.www7.hp.com for a list of fully supported OpenVMS
applications. Section 29.3.4 describes in greater detail the impact of
ODS-5 on OpenVMS applications.
29.3.2 Considerations for Users
Users of OpenVMS I64 and OpenVMS Alpha Version 7.2 and higher systems can take advantage of all Extended File Specifications capabilities on ODS-5 volumes mounted on an OpenVMS I64 and OpenVMS Alpha Version 7.2 and greater system.
Users of mixed-version or mixed-architecture OpenVMS Clusters are
subject to some limitations in ODS-5 functionality. Section 188.8.131.52
lists those restrictions that exist on a mixed-version OpenVMS Cluster.
Section 184.108.40.206 lists those restrictions that exist on a
mixed-architecture OpenVMS Cluster.
220.127.116.11 Mixed-Version Support
Systems running prior versions of OpenVMS cannot mount ODS-5 volumes, correctly handle extended file names, or even see extended file names.
The following sections describe support on OpenVMS Version 7.2 and greater and on prior versions of OpenVMS in a mixed-version cluster.
OpenVMS I64 and OpenVMS Alpha Version 7.2 and higher system can continue to access pre-Version 7.2 files and directories; for example, users can do all of the following:
On mixed-version clusters, some restrictions exist. Users on a version of OpenVMS prior to Version 7.2:
Current ODS-2 volume and file management functions remain the same on VAX, Alpha Version 7.2 and greater systems, and I64 systems; however, extended file naming and parsing are not available on VAX systems.
The following sections describe support on OpenVMS VAX, Alpha, and I64 systems in a mixed-architecture cluster.
In mixed-architecture OpenVMS Version 7.2 and greater clusters, OpenVMS Version 7.2 and greater VAX systems are limited to the following Extended File Specifications functionality:
From a VAX system, users cannot successfully create or restore an ODS-5
image saveset. However, these users can successfully restore
ODS-2-compliant file names from an ODS-5 saveset.
29.3.3 NFS Support for Extended File Specifications
The NFS server and the NFS client support OpenVMS extended file specifications (EFS) on ODS-5 disk volumes.
You can use NFS server to export files on OpenVMS ODS-5 volumes. The traditional ODS-2 volumes continue to be supported. The NFS client can emulate an ODS-5 volume.
Note that the NFS server and NFS client support the ISO Latin-1 character set only.
If an ODS-5 volume is mapped and exported, the NFS server automatically supports EFS features and ignores the NAME_CONVERSION option of the EXPORT command, if it is specified in the export record.
On ODS-2 volumes (with or without the NAME_CONVERSION option), files with all uppercase names are displayed on non-OpenVMS clients with all lowercase letters. On ODS-5 volumes, the file names are displayed by clients in the same case as they are displayed locally on the server host.
If an ODS-2 volume contains file names that were created using the
NAME_CONVERSION option of the NFS EXPORT command and include lowercase
or special characters that are invalid for ODS-2 file names, those file
names displayed locally on the server host contain character sequences
(escape codes), as described in HP TCP/IP Services for OpenVMS
Management. If the DCL SET VOLUME /STRUCTURE_LEVEL=5 command is
performed on this volume, the names are displayed by clients with the
character sequences exactly as they are displayed locally on the server
29.3.4 Considerations for Applications
ODS-5 functionality can be selected on a volume-by-volume basis. If ODS-5 volumes have not been enabled on your system, all existing applications will continue to function as before. If ODS-5 volumes have been enabled, you need to be aware of the following changes:
On ODS-5 volumes, existing applications and layered products that are coded to documented interfaces, as well as most DCL command procedures, should continue to work without modification.
However, applications that are coded to undocumented interfaces, or include any of the following, may need to be modified in order to function as expected on an ODS-5 volume:
The data layout on disk
The contents of file headers
The contents of directory files
All unmodified XQP applications running on an OpenVMS VAX, OpenVMS Alpha, or OpenVMS I64 system that access an ODS-5 volume will see pseudonames returned in place of Unicode or ISO Latin-1 names that are not ODS-2 compliant. This can cause applications to act in an unpredictable manner.
Applications that specify or retrieve filenames with the XQP interface using ODS-5 disks must be modified in order to access files with extended names.
This section describes considerations for applications and how to
evaluate an application's support for Extended File Specifications.
29.4.1 Evaluating Your Current Support Status
Any applications that are coded to undocumented interfaces may not provide support for either deep directories or extended file names. Section 29.4.3 lists additional application attributes that may prevent an application from supporting extended file names. Section 29.4.4 lists additional application attributes that may prevent an application from supporting ODS-5 volumes.
You can choose either to modify these applications to support Extended
File Specifications or not to use them under Extended File
Specifications. For information on how to modify an application to
provide default support for Extended File Specifications, see
Section 29.5.1. For information on how to upgrade an application to
full support, see Section 29.5.2.
29.4.2 Default Support
Most unmodified OpenVMS applications fall into the default support
category. Specifically, these applications use the traditional API
rather than the new API when making RMS calls. Applications that use
high-level language calls to perform file operations will also fit into
this category unless the language run-time libraries have been modified
to full support. In most cases, you will not need to modify these
applications for them to function successfully under Extended File
29.4.3 No Support for Extended File Names
An application that does any of the following may not support extended file names:
An application that uses internal knowledge of the file system,
including knowledge of the contents of a directory and how file header
data is structured on a disk cannot work correctly on an ODS-5 volume.
29.5 Upgrading an Application to Support Extended File Specifications
The following sections describe the changes necessary to upgrade the level of support for extended file specifications. Note that you must first ensure that the application meets the default support level before you can upgrade it to the full support level.
If you are not using the RMS or QIO interfaces to perform disk I/O, the Extended File Specifications support level of your application depends on whether the interface you are using (such as a language run-time library) provides full support.
To upgrade an application to provide default support for Extended File
Specifications, you must ensure that it minimally supports both the
ODS-5 volume structure and extended file naming as recommended in
naming as recommended in Sections 18.104.22.168 and 22.214.171.124,
respectively. Default support is defined in Section 29.4.2.
126.96.36.199 Providing Support for ODS-5
Applications that do not support the new ODS-5 volume structure do not operate successfully on these volumes even if they encounter only traditional file specifications.
If an application does not work properly on an ODS-5 volume, examine the application for the following: