HP OpenVMS Programming Concepts Manual
Overview of Extended File Specifications (Alpha and I64 Only)
Alpha OpenVMS Version 7.2 and greater and OpenVMS I64 implement
Extended File Specifications, which consists of two major components:
- An optional volume structure, ODS-5, which provides support for
file names that are longer and have a greater range of legal characters
than in previous versions of OpenVMS
- Support for deep directories
Taken together, these components provide much greater flexibility for
OpenVMS Alpha systems (using Advanced Server for OpenVMS formerly known
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:
- Users of Advanced Server for OpenVMS V7.2 and later
(formerly known as PATHWORKS for OpenVMS) have the ability to store
longer file names, preserve the case of file names, and use deeper
directory structures. These new capabilities make the use of an OpenVMS
file server more transparent to Windows users.
- OpenVMS system managers can see files on OpenVMS systems with the
names as specified by Windows users.
- Applications developers who are porting applications from other
environments that have support for deep directories can use a parallel
structure on OpenVMS.
- Longer file naming capabilities and Unicode support enables
OpenVMS to act as a
DCOM server for Windows clients, and ODS-5 provides capabilites that
make the OpenVMS and Windows environment more homogeneous for DCOM
Java® applications on OpenVMS will comply with
Java® object naming standards.
- General OpenVMS users can make use of long file names, new
character support, and the ability to have lowercase and mixed-case
These benefits result from the features described in Section 29.2.
29.2 Features of Extended File Specifications
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:
- Long file names
- More characters legal within file names
- Preservation of case within file names
These features are described in the sections that follow.
18.104.22.168 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.
22.214.171.124 More Characters Legal Within File Names
A broader set of characters is available for naming files on OpenVMS.
ODS-5 offers support for file names that use the 8-bit ISO Latin-1
character and 16-bit
Unicode (UCS-2) character sets.
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
126.96.36.199 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
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
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
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
Both ODS-2 and ODS-5 volume structures support deep nesting of
directories, subject to the following
- There can be up to 255 levels of directories.
- The name of each directory can be up to 236 8-bit or 118 16-bit
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
Complete file specifications longer than 255 bytes are abbreviated by
RMS when presented to unmodified applications.
188.8.131.52 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
ODS-5 provides enhanced file sharing capabilities for users of Advanced
Server for OpenVMS 7.2
(formerly known as PATHWORKS for OpenVMS), as well as
DCOM and JAVA applications.
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:
- Users must access ODS-5 files and deep directories from OpenVMS I64
and OpenVMS Alpha V7.2 and greater systems only, because these
capabilities are not supported on earlier versions.
- Users who have created deep directories can view those directories
only from OpenVMS I64 and OpenVMS Alpha V7.2 and greater systems.
- Pre-Version 7.2 systems cannot mount an ODS-5 volume nor read ODS-2
or ODS-5 file names on that volume.
Section 29.3.2 describes in greater detail the limitations of ODS-5
support for users in a mixed-version or mixed-architecture OpenVMS
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 184.108.40.206
lists those restrictions that exist on a mixed-version OpenVMS Cluster.
Section 220.127.116.11 lists those restrictions that exist on a
mixed-architecture OpenVMS Cluster.
18.104.22.168 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 Systems
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:
- Create and access deep directory structures on ODS-2 volumes.
- Read a BACKUP saveset created on an earlier version of OpenVMS.
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 of Pre-Version 7.2 Systems
On mixed-version clusters, some restrictions exist. Users on a version
of OpenVMS prior to Version 7.2:
- 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 bus, or
by an MSCP or QIO server.
- 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.
22.214.171.124 Mixed-Architecture Support
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.
Limited Extended File Specifications Capabilities on VAX Systems
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:
- Ability to mount an ODS-5 volume
- Ability to write and manage ODS-2-compliant files on an ODS-5
- See pseudonames (
) when accessing an ODS-5 file specification
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
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:
- OpenVMS file handling and command line parsing have been modified
to enable them to work with extended file names on ODS-5 volumes while
still being compatible with existing applications. The majority of
existing, unprivileged applications will work with most extended file
names, but some may need modifications to work with all extended file
- Privileged applications that use physical or logical I/O to disk
may require modifications and should be analyzed. Applications that
have a specific need to access ODS-5 file names or volumes should be
analyzed to determine if they require modification.
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:
- Internal knowledge of the file system, including knowledge of:
The data layout on disk
The contents of file headers
The contents of directory files
- File parsing tailored to a particular on-disk structure.
- Assumptions about the syntax of file specifications, such as the
placement of delimiters and legal characters.
- Assumptions about the case of file specifications. Mixed and
lowercase file specifications will not be converted to uppercase, which
can affect string matching operations.
- Assumptions that file specifications are identical between RMS and
the file system.
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
Applications that specify or retrieve filenames with the XQP interface
using ODS-5 disks must be modified in order to access files with
29.4 Extended File Naming Considerations for OpenVMS Application Developers
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
- Uses the
QIO interface to specify file names. Developers should examine all
layered products and applications and evaluate any file name
interaction between the RMS and the XQP interfaces. The format for
extended file names varies for each interface. As a result, an
application can no longer assume that it can use the same file name for
both RMS and the XQP. In addition, the XQP does not allow an unmodified
application to use extended file names. Valid file names could differ
- Makes assumptions about the syntax of file specifications, such as
the placement of delimiters and legal characters.
- Makes assumptions about the case of file specifications. RMS no
longer converts mixed and lowercase file specifications to uppercase in
all cases. This could affect string matching operations.
- Depends on the traditional directory depth (fewer than 8 levels).
29.4.4 No Support for ODS-5 Volumes
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.
29.5.1 Upgrading to Default 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 126.96.36.199 and 188.8.131.52,
respectively. Default support is defined in Section 29.4.2.
184.108.40.206 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:
- Does the application use physical or logical I/O to bypass the
file system when accessing the volume, or does it access metadata files
such as BITMAP.SYS directly? These applications are usually system
programs, such as disk defragmenters, or programs that try to avoid
overhead by accessing the disk directly. These applications rely on
specific knowledge of the file or directory structure on the disk,
which has changed with introduction of the ODS-5 structure.
Recommendation: Applications should use documented
interfaces and structures whenever possible.
- Does the application access and interpret the contents of
directory files directly? If so, the application may fail when it
encounters a directory that contains extended file names.
Recommendation: Modify the application to use the search
functions provided with the RMS or
QIO interface, or with LIBRTL routines such as LIB$FIND_FILE.