VMS Help  —  Ext File Specs
    Extended File Specifications is a feature of OpenVMS Alpha that
    allows the use of Windows-style file specifications.

1  –  Overview

    Extended File Specifications includes support for the following:

    o  The ODS-5 disk structure. ODS-5 is an extension to the
       existing ODS-2 disk structure, and adds the ability to use
       extended file names that can be more easily mapped between
       Windows and OpenVMS. ODS-5 expands the available character
       set and filename length to be consistent with Windows 95 and
       Windows NT, and sets the stage for future Unicode file name
       support through PATHWORKS.

    o  Deeper directories. Enhancements to RMS provide deep directory
       support on both ODS-2 and ODS-5 volumes.

    Taken together, these components provide much greater flexibility
    for OpenVMS Alpha systems (using Advanced Server for OpenVMS
    7.2, formerly known as PATHWORKS for OpenVMS), to store, manage,
    serve, and access files that have names similar to those in a
    Windows 95 or Windows NT environment.

    This topic provides an overview of the benefits, features,
    and support for Extended File Specifications, as well as
    changes in OpenVMS behavior that occur when using Extended File
    Specifications.

1.1  –  Benefits

    The deep directories and extended file names supported by
    Extended File Specifications provide the following benefits:

    o  OpenVMS system managers can manage files with extended names
       and deep directories in the same manner as Windows NT users.

    o  Users of Advanced Server for OpenVMS 7.2 (formerly known as
       PATHWORKS for OpenVMS) have the ability to store longer file
       names and use deeper directory structures, which are more
       compatible with Windows 95 and Windows NT file names.

    o  Applications developers who are porting applications from
       other environments that have support for deep directories can
       use a parallel structure on OpenVMS.

    o  Longer file naming capabilities and Unicode support enables
       OpenVMS Alpha Version 7.2 and later to act as a DCOM server
       for Windows NT clients, and ODS-5 provides capabilites that
       make the OpenVMS and Windows NT environment more homogeneous
       for DCOM developers.

    o  JAVA applications on OpenVMS will comply with JAVA object
       naming standards.

    o  General OpenVMS users can make use of long file names, new
       character support, and the ability to have lowercase and
       mixed-case file names.

1.2  –  Features

    Extended File Specifications consists of two main features, the
    ODS-5 volume structure, and support for deep directories.

1.2.1  –  ODS-5

    OpenVMS Alpha Version 7.2 and later 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 enable ODS-5 volumes on your OpenVMS Alpha
    systems.

    The ODS-5 volume structure allows the following features:

    o  Long file names

    o  More characters legal within file names

    o  Preservation of case within file names

1.2.2  –  Deep Directories

    Both ODS-2 and ODS-5 volume structures support deep nesting of
    directories, subject to the following limits:

    o  There can be up to 255 levels of directories.

    o  The name of each directory can be up to 236 8-bit or 117
       16-bit characters long.

    Complete file specifications longer than 255 bytes are
    abbreviated by RMS when presented to unmodified applications.

    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]

1.2.2.1  –  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.

1.3  –  Considerations

    ODS-5 is being introduced primarily to provide 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.

    System managers must understand the impact of an ODS-5
    environment before enabling it for general users. It is essential
    that system managers perform the following steps before enabling
    ODS-5:

    o  Review all ODS-5 restrictions.

    o  Understand the support levels for different OpenVMS
       applications.

    o  Segregate applications that do not support ODS-5 or have not
       been tested with ODS-5 names or volumes.

                                   NOTE

       It is recommended that you enable ODS-5 disks in a
       homogeneous OpenVMS Version 7.2 (and later) Alpha cluster
       only.

1.3.1  –  Mixed-Version Support

    Users on OpenVMS Alpha 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, correctly handle extended file names, or even see
    extended file names.

    The following topics describe support on OpenVMS Version 7.2
    (and later) and on prior versions of OpenVMS in a mixed-version
    cluster.

    Users on OpenVMS Alpha Version 7.2 (and later) Systems

    Users on OpenVMS Alpha Version 7.2 and later systems can continue
    to access pre-Version 7.2 files and directories; for example,
    they can do all of the following:

    o  Create and access deep directory structures on ODS-2 volumes.

    o  Read a BACKUP saveset created on an earlier version of
       OpenVMS.

    o  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 pre-Version 7.2 Systems

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

    o  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.

    o  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.

1.3.2  –  Mixed-Architecture Support

    All Extended File Specifications capabilities are available on
    OpenVMS Alpha Version 7.2 and later systems. Current ODS-2 volume
    and file management functions remain the same on both VAX and
    Alpha Version 7.2 (and later) systems; however, extended file
    naming and parsing are not available on VAX systems.

    The following topics 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 (and later) clusters,
    the following Extended File Specifications capabilities are
    available on OpenVMS Version 7.2 (and later) VAX systems:

    o  Ability to mount an ODS-5 volume

    o  Ability to write and manage ODS-2-compliant files on an ODS-5
       volume

    o  See only \pISO_LATIN\.??? or \pUNICODE\.??? when accessing an
       ODS-5 file specification

    BACKUP Limitations

    In a mixed architecture cluster, 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.

1.3.3  –  Network Support

    Although Extended File Specifications is intended to provide
    enhanced file naming capabilities to Advanced Server for OpenVMS
    7.2 Version 7.2 for OpenVMS Version 7.2, network access with
    ODS-5 volumes and extended file names is currently being tested.
    The length of an extended file specification that can be passed
    over the network using DECnet is restricted to a maximum of 255
    bytes.

1.3.4  –  Application Support

    OpenVMS applications should be evaluated and tested to determine
    whether they function correctly when Extended File Specifications
    is enabled. The OpenVMS System Manager's Manual, Volume 1:
    Essentials contains guidelines for evaluating applications, and
    the Guide to OpenVMS File Applications contains details about the
    technical aspects of Extended File Specifications that can affect
    the behavior of an application.

1.3.5  –  User Support

    When you enable ODS-5 volumes on an OpenVMS cluster, you should
    make users aware of the following characteristics:

    o  Extended file names caooonot be used on ODS-2 volumes.

    o  Case is determined by the first instance of an extended file
       name.

    o  There are special rules for case preservation and case
       blindness when using extended file names.

    o  Some system utilities and DCL commands have a /STYLE qualifier
       to control the display of file names.

    o  Error messages can vary when different parse style are used.

    o  Extended file names are not visible from a VAX system.

    The OpenVMS System Manager's Manual, Volume 1: Essentials
    contains information for setting user's expectations of Extended
    File Specifications.

1.4  –  Impact

    The main goal of Extended File Specifications is to provide
    extended file naming capabilities, while also:

    o  Maintaining high reliability, scalability, and availability

    o  Maintaining the traditional (ODS-2) serial file interoperation
       capabilities

    o  Causing the least possible amount of change for layered
       products and applications

    However, 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 following guidelines and description of changes in the base
    operating system will help you determine the level of impact on
    your OpenVMS environment.

1.4.1  –  Support Guidelines

    Under Extended File Specifications, 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:

    o  Internal knowledge of the file system, including knowledge
       of:

          The data layout on disk
          The contents of file headers
          The contents of directory files

    o  File parsing tailored to a particular on-disk structure.

    o  Assumptions about the syntax of file specifications, such as
       the placement of delimiters and legal characters.

    o  Assumptions about the case of file specifications. Mixed
       and lowercase file specifications will not be converted to
       uppercase, which can affect string matching operations.

    o  Assumptions that file specifications are identical between RMS
       and the file system.

                                   NOTE

       All unmodified XQP applications running on an OpenVMS
       VAX or Alpha 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.

1.4.2  –  RMS Changes

    To support Extended File Specifications, the Record Management
    Services (RMS) have been enhanced to provide the following
    functions through existing interfaces:

    o  Support for a wider range of characters in a file name,
       extension, and directory

    o  Access to file specifications with extended characters

    o  Support for directory structures deeper than eight levels

    o  Access to file specifications longer than 255 bytes through
       the NAM block with some restrictions in functionality

    o  Access and complete specification of file specifications
       longer than 255 bytes by callers who are aware of the new
       naming characteristics through a new interface (NAML block)

1.4.2.1  –  Extended File Names

    With ODS-5 enabled, RMS can manipulate filenames and subdirectory
    specifications of up to 255 8-bit or 16-bit characters in length.
    RMS can handle a total path name 512 8-bit or 16-bit characters
    in length.

    Prior to OpenVMS Alpha Version 7.2, the NAM block interface could
    pass file specifications of up to 255 bytes each (including the
    resultant file specification). The following topics describe the
    changes that allow for passing longer file specifications and
    that provide compatibility with applications using the NAM block
    interface prior to this release.

1.4.2.2  –  Additional Character Sets

    With ODS-5, RMS supports access to files and directories whose
    names contain arbitrary 8-bit characters, except for the C0
    control set (hex 00 through 1F) and the following characters:

       Double quotation marks (")
       Asterisk (*)
       Backslash (\)
       Colon (:)
       Left and right angle brackets (< >)
       Slash (/)
       Question mark (?)
       Vertical bar (|)

    Note that this explicitly includes both the C1 character set (hex
    80-9F) as well as graphical and other characters between 9F and
    FF. This allows the entire ISO Latin-1 character set (with the
    7-bit character exclusions noted above) and any defined Unicode
    character.

1.4.2.3  –  Deeply Nested Directories

    Under Extended File Specifications on Alpha, RMS supports deep
    nesting of up to 255 directories, with the restriction that the
    total directory specification must be no longer than 512 8-bit
    or 16-bit characters. The deep nesting of directories is also
    supported on ODS-2 disks.

1.4.3  –  File System (XQP) Changes

    The following Files-11 Extended QIO Processor (XQP) file system
    enhancements are offered under Extended File Specifications
    through the $QIO interface. Note that in some cases, XQP file
    format rules may differ from those that apply to other system
    services that accept file names, such as those provided by RMS.

    o  The current restrictions on the format and content of file
       names have been modified, specifically:

       -  The 39.39 file name length restriction was removed to allow
          longer file names, up to 236 8-bit characters or 117 16-bit
          characters

       -  The use of characters from the ISO Latin-1 multinational
          character set is supported in file specifications

       -  Support for the entry and storage of file and directory
          specifications in Unicode.

1.4.4  –  DCL Commands and Utilities

    In DCL commands, you can select either of the following styles
    for parsing file specifications:

    o  Traditional filenames are allowed on both ODS-2 and ODS-5
       volumes.

    o  Extended filenames are allowed on ODS-5 but not on ODS-2
       volumes.

    Some OpenVMS commands and utilities have new qualifiers to
    control the interpretation and display of file specifications.

                                   NOTE

       DCL lexical functions use the DEC-Multinational character
       set, which is different from the ISOLatin-1 character set
       used for file names on an ODS-5 disk. This can lead to
       unexpected results if, for example, you use the DCL function
       F$EDIT to upcase a filename.

    Some DCL commands and OpenVMS utilities have been specifically
    modified to take advantage of all the features of extended file
    names. These utilities and commands accept and handle extended
    file specifications without error and without modifying their
    expected case.

    Other DCL commands and OpenVMS utilities have had little or
    no modification to take advantage of extended file names.
    These utilities and commands are expected to handle most of
    the attributes of extended file specifications (such as new
    characters and deep directory structures) correctly.

    Extended File Specifications Support fully defines the different
    levels of support for extended file names provided by DCL
    commands and OpenVMS utilities in OpenVMS Version 7.2 and later.

    The following DCL commands and OpenVMS utilities provide full
    support for extended file names:

       ANALYZE /AUDIT
       ANALYZE /DISK
       ANALYZE /RMS
       BACKUP
       CONVERT
       CONVERT /RECLAIM
       COPY
       CREATE /DIRECTORY
       DELETE
       DIRECTORY
       DUMP
       EDIT /ACL
       EXCHANGE /NETWORK
       FDL
       PURGE
       RECOVER/RMS
       RENAME
       SEARCH
       SET SECURITY
       SYSMAN
       TYPE

 The following table lists the new features in DCL to support
 Extended File Specifications.

    DCL Command            New Features

    COPY                   Added new qualifier, /STYLE, with new
                           keywords, EXPANDED and CONDENSED
    DELETE                 Added new qualifier, /STYLE, with new
                           keywords, EXPANDED and CONDENSED
    DIRECTORY              Added the following items:

                           o  Qualifier, /STYLE, with new keywords,
                              EXPANDED and CONDENSED

                           o  Display item to /FULL to display Client
                              Attributes

    DUMP                   Added the following items:

                           o  Display item to /DIRECTORY to display
                              Name type attribute

                           o  Display item to /HEADER to display new
                              attributes

                           o  Qualifier, /STYLE, with new keywords,
                              EXPANDED and CONDENSED

    EXCHANGE NETWORK       Added new qualifier, /STYLE, with new
                           keywords, EXPANDED and CONDENSED
    F$FILE_ATTRIBUTES      Added new item codes: FILE_LENGTH_HINT,
    Lexical                VERLIMIT, DIRECTORY
    F$GETDVI Lexical       Added new type to the ACPTYPE item code.
    F$GETJPI Lexical       Added new item codes: PARSE_STYLE_PERM and
                           PARSE_STYLE_IMAGE
    INITIALIZE             Added a new qualifier: /STRUCTURE=5
                           device-name[:] volume-label
    PRINT                  Added new qualifier, /STYLE, with new
                           keywords, EXPANDED and CONDENSED
    PURGE                  Added new qualifier, /STYLE, with new
                           keywords, EXPANDED and CONDENSED
    RENAME                 Added new qualifier, /STYLE, with new
                           keywords, EXPANDED and CONDENSED
    SEARCH                 Added new qualifier, /STYLE, with new
                           keywords, EXPANDED and CONDENSED
    SET ACL                Added new qualifier, /STYLE, with new
                           keywords, EXPANDED and CONDENSED
    SET DEFAULT            Updated the following items:

                           o  Modified the directory-spec parameter
                              to accept ODS-5-compliant file
                              specifications.

    SET DIRECTORY          Added new qualifier, /STYLE, with new
                           keywords, EXPANDED and CONDENSED
    SET FILE               Added new qualifier, /STYLE, with new
                           keywords, EXPANDED and CONDENSED
    SET PROCESS            Added a new qualifier: /PARSE_
                           STYLE=(keyword), where keywords are
                           TRADITIONAL and EXTENDED.
    SET SECURITY           Added new qualifier, /STYLE, with new
                           keywords, EXPANDED and CONDENSED
    SET VOLUME             Added a new qualifier: /STRUCTURE_LEVEL=5
    SHOW DEVICE/FULL       Updated the display information to show
                           the disk structure level.
    SUBMIT                 Added new qualifier, /STYLE, with new
                           keywords, EXPANDED and CONDENSED
    TYPE                   Added new qualifier, /STYLE, with new
                           keywords, EXPANDED and CONDENSED

    For detailed information about the enhancements made to the
    OpenVMS operating system and utilities in support of Extended
    File Specifications, see the OpenVMS DCL Dictionary: A-M, the
    OpenVMS DCL Dictionary: N-Z, and the OpenVMS Utility Routines
    Manual.

1.4.5  –  DCL Command Parameters

    Command procedures that use file names as parameters can produce
    different results in an ODS-5 environment.

    See DCL Command Parameters for more information about using ODS-5
    style names in DCL command procedures.

1.4.6  –  System Services Changes

    The following system services have been modified or added to
    support Extended File Specifications:

    o  New services:

       -  $SET_PROCESS_PROPERTIESW

       -  $CVT_FILENAME

    o  Changed services:

       -  $CREPRC

       -  $GETJPI

       -  $SETDDIR

2  –  Managing

    Managing an OpenVMS system that implements Extended File
    Specifications requires an understanding of the support provided
    for different OpenVMS applications, how to enable and control
    the new features, and the changes to OpenVMS system management
    utilities. This topic contains the following subtopics:

    o  Levels of support provided by the current set of OpenVMS
       commands and utilities that support Extended File
       Specifications

    o  How to enable Extended File Specifications features on an
       OpenVMS Alpha system

    o  How to control user access to ODS-5 features

    o  Changes to system management utilities

2.1  –  Extended File Specifications Support

    To help determine the expected behavior of OpenVMS utilities
    and commands for ODS-5, the following levels of support have
    been established. Each level outlines the acceptable behavior
    of a utility or command when it encounters an extended (ODS-5
    compliant) file specification.

    The levels of support for ODS-5 are defined in the following
    sections:

2.1.1  –  Full Support

    OpenVMS utilities and commands that offer full support for ODS-5
    have been specifically modified to take advantage of all the
    features of extended file naming. These utilities and commands
    should accept and handle extended file specifications without
    error and without modifying their expected case.

    In addition, OpenVMS commands and utilities that fully support
    Extended File Specifications can accept and produce long file
    specifications that exceed the traditional 255-byte limit in
    their original form-without requiring them to be abbreviated in
    Directory ID (DID) or File ID (FID) format.

2.1.2  –  Default Support

    OpenVMS utilities and commands with default support have had
    little or no modification to take advantage of Extended File
    Specifications features. These utilities and commands are
    expected to handle most of the attributes of extended file
    specifications (such as new characters and deep directory
    structures) correctly. However, issues with case sensitivity
    and case blindness (such as converting lowercase characters to
    uppercase) may occur.

    In contrast with utilities that have full support, utilities with
    default support rely on DID and FID abbreviation offered by RMS
    to handle long file specifications. As a result, these utilities
    are subject to the following restrictions related to DID and FID
    abbreviation:

    o  Matching operations in an environment where FID abbreviation
       is used may not always work as expected. For example, wildcard
       matching operations may not capture all target file names
       because the long file names may be represented in their
       numeric FID abbreviation form. This restriction specifically
       applies to matching operations that are performed outside of
       RMS.

    o  Wildcards and sticky defaults cannot be used with a FID
       abbreviation. For example, the following commands are illegal:

       $ DIRECTORY a[1,2,3]*.txt
       $ COPY a[1,2,3].txt *.txt2

       Because FID abbreviations are a unique numeric representation
       of one file, they cannot be used to represent or match any
       other file.

    o  Creating a file using a FID abbreviation is illegal.

2.1.3  –  No Support for Extended File Naming

    OpenVMS utilities and commands that do not support extended
    file naming can function on ODS-5 volumes; however, they are
    restricted to operating with traditional file specifications
    only. These utilities and commands should be used carefully
    under Extended File Specifications because they may not function
    successfully when they encounter extended file specifications.

2.1.4  –  No Support for ODS-5

    OpenVMS utilities and commands that do not support the ODS-
    5 volume structure cannot handle extended file naming. These
    utilities and commands should be used carefully under Extended
    File Specifications because they may not function successfully
    on ODS-5 volumes even when they only encounter traditional file
    specifications.

    The following table lists the OpenVMS utilities and commands
    that do not support Extended File Specifications because of
    limitations with either handling extended file names or the ODS-5
    volume structure.

    Component              Notes

    No ODS-5 Support

    Disk defragmenters     Unsupported unless a specific
                           defragmentation tool documents that it has
                           been updated to support an ODS-5 volume.

    No Extended File Naming Support

    Code compilers         Cannot use extended file names for object
                           files. However, code compilers can create
                           applications that support extended names.
    INSTALL
    Known images           Do not rename to an extended file name.
    LINK                   Cannot output an image with an extended
                           file name.
    Network files          Do not rename to an extended file name.
    (NET*.DAT)
    Object modules (.OBJ)  Do not rename to an extended file name.
    Page and swap files    Do not use an extended file name.
    SYSGEN                 Do not write a parameter file with an
                           extended file name.
    System startup files   Do not rename to an extended file name.

3  –  Using

    Extended file names provide a wider variety of character set
    options and naming conventions, similar to those available on
    Windows NT. This topic describes the impact of Extended File
    Specifications on the general user, and contains the following
    subtopics:

    o  Differences in file and directory specifications between ODS-2
       and ODS-5

    o  Manipulating extended file names

    o  Using extended file names in DCL command procedures

    o  Displaying ODS-5 file specifications in DECwindows

3.1  –  File Specification Differences

    With extended file names, there are two possible naming styles
    for file specifications: traditional (ODS-2 compliant) and
    extended (ODS-5 compliant). The following topics describe these
    naming styles.

    See also the OpenVMS User's Manual and the Guide to OpenVMS File
    Applications for more information about file specifications in
    Extended File Specifications.

3.1.1  –  ODS-2 Syntax

    The traditional (ODS-2) file name syntax is the syntax most
    OpenVMS users have been accustomed to up to the advent of
    extended file names. OpenVMS Versions 7.1 and earlier follow this
    syntax, which supports the following character set and naming
    conventions.

    ODS-2 Character Set

    The ODS-2 character set consists of alphanumeric characters (A-Z,
    a-z, 0-9), dollar sign ($), underscore (_) and hyphen (-). The
    hyphen (-) should not be used as the first or last character in a
    file name. While it is possible to do this under some conditions,
    special handling is required to access such a file once created.

    Case Insensitivity

    Case preservation is not supported with traditional syntax.
    Commands may be entered in uppercase, lowercase, or mixed case;
    however, all characters are stored in uppercase format.

    Standard Delimiters

    With traditional syntax, the file type is preceded by a period
    (.). The file version is separated from the type by a semicolon
    (;) or sometimes a period (.). (When the system displays file
    specifications, it displays a semicolon in front of the file
    version number.) Directories are enclosed by brackets ([]) or
    angle brackets (<>). Directory levels are separated by periods
    (.).

    Limited File Length

    Traditional file names follow the 39.39 format, supporting only a
    single period (.) separating the name and type components.

3.1.2  –  ODS-5 Syntax

    The extended (ODS-5) file name syntax offered by Extended File
    Specifications supports a larger character set and relaxes
    restrictions on lengths of file names and use of characters. This
    syntax allows Windows NT-style file names that use the following
    character set and naming conventions to be stored on and accessed
    by OpenVMS systems.

3.1.2.1  –  Character Set Support

    The ISO Latin-1 Multinational character set is a superset
    of the traditional ASCII character set used by versions of
    OpenVMS previous to 7.2. With extended file specifications, all
    characters from the 8-bit ISO Latin-1 Multinational character set
    are valid in file specifications, except the following:

       C0 control codes (0x00 to 0x1F inclusive)
       Double quotation marks (")
       Asterisk (*)
       Backslash (\)
       Colon (:)
       Left angle bracket (<)
       Right angle bracket (>)
       Slash (/)
       Question mark (?)
       Vertical bar (|)

    File specifications on an ODS-5 volume can also include Unicode
    (UCS-2) characters. Because each Unicode character requires
    two bytes, the use of Unicode characters can affect the maximum
    permitted lengths of file specifications.

3.1.2.2  –  Special Characters

    Some ISO Latin-1 characters require the circumflex (^) to precede
    them in a file specification in order to be interpreted as
    literal characters rather than special function characters.
    The circumflex (^) is interpreted by the system as an escape
    character.

    o  The circumflex (^) followed by underscore (_) or by a space
       represents a space.

    o  The circumflex (^) followed by any of the following characters
       means that the character is to be used as part of a file name
       rather than having any special meaning that it might otherwise
       have in a file specification:

       .  ,  ;  [  ]  %  ^  &

    o  A user can enter a literal period (.) with or without the
       circumflex (^) in a file name. The system adds the circumflex
       to any periods other than those that act as delimiters for the
       file type and version number. Literal periods (.) in directory
       names must be preceded by the circumflex.

       File names containing special characters cannot be accessed
       from a VAX system.

3.1.2.3  –  Interpretation of Period

    The introduction of the period (.) as a literal character in
    extended file names requires RMS to determine which periods are
    file name characters and which are delimiters.

    When only one period (.) is used in an extended file name, that
    period is interpreted as the delimiter, as in "Venice.Venezia;1"
    above. As in previous versions of OpenVMS, this behavior also
    occurs if the single period is followed by a number:

    $ CREATE Test.1

    creates the file:

    Test.1;1

    When there are multiple periods (.) in a file name, the system
    looks at all the characters after the last period. If those
    characters are five or fewer digits, or a minus sign (-) followed
    by five or fewer digits, the period is interpreted as a version
    delimiter and the period previous to it is a type delimiter.
    Notice that a legal version is less than or equal to 32767.
    If you try to create the file "grandioso.x.33333", the "33333"
    causes an illegal version error. If there is a nonnumeric
    character following the last period then it is interpreted as
    a type delimiter.

    For example, the following command: $ CREATE Test4.3.2.1

    creates the file: Test4^.3.2;1

    where .2 is the file type and 1 is the file version.

3.1.3  –  Expanded File Specification Length

    On an ODS-5 volume, the file name together with the file type
    can be up to 236 8-bit characters of 117 16-bit characters in
    length. Unmodified programs and utilities may limit or abbreviate
    complete file specifications to 255 bytes.

    $ CREATE This.File.Name.Has.A.Lot.Of.Periods.DAT
    $ CREATE -
    _$ ThisIsAVeryLongFileName^&ItWillKeepGoingForLotsAndLotsOfCha -
    _$ racters.ExceedingThe39^,39presentInPreviousVersionsOfOpenVMS
    $ DIRECTORY

    Directory TEST$ODS5:[TESTING]

    ThisIsAVeryLongFileName^&ItWillKeepGoingForLotsAndLotsOfCharac
    ters.ExceedingThe39^,39presentInPreviousVersionsOfOpenVMS;1
    This^.File^.Name^.Has^.A^.Lot^.Of^.Periods.DAT;1

    Total of 2 files.

3.1.4  –  Case Preservation

    Mixed-case and lowercase file names are retained in their
    original form on ODS-5 volumes. However, the file system on
    OpenVMS preserves the case of file names as they are first
    entered. When you create more than one file with the same name
    differing only in case, DCL treats the subsequent files as
    versions, and converts them to the same case as the original
    file.

    For example, the following commands:

    $ CREATE CaPri.;1
    $ CREATE CAPRI
    $ CREATE capri

    produce the resulting files:

    CaPri.;1  CaPri.;2  CaPri.;3

3.1.5  –  Using Wildcards

    Single- and multiple-character wildcards still function as
    expected with ODS-5 files. A single-character wildcard represents
    exactly one character in either the file name or file type, but
    may not be used in the file version string. A multiple-character
    wildcard can represent any number of characters starting with
    zero in the file name or file type. A multiple-character wildcard
    can be used in place of a version string.

3.1.5.1  –  Wildcard Characters

    The following characters are wildcard characters when working on
    any OpenVMS 7.2 or later volume:

    o  The asterisk (*) is a multiple-character wildcard.

    o  The percent sign (%) is a single-character wildcard.

    o  The question mark (?) is a single-character wildcard.

    The percent sign (%) continues to be a single-character wildcard
    to maintain compatibility with existing applications. The percent
    sign (%) may be used as a literal character when preceded by
    the circumflex (^) and is also a literal character in Windows NT
    file names. Therefore, in addition to the percent sign, RMS also
    recognizes the question mark (?) as a single character wildcard.
    The question mark functions identically to the percent sign as
    a wildcard character on OpenVMS 7.2 and later. The percent sign
    and the question mark matches exactly one character in a search
    pattern.

3.1.5.2  –  Wildcard Syntax

    Although DCL preserves the case of extended file names, wildcard
    matching is case blind.

    When you perform a search operation with wildcards it continues
    to match only against the corresponding character in the same
    part of the target specification. The following table contains
    examples of some wildcard searches.

    The
    pattern...     matches...             ...but doesn't match

    A*B;*          AHAB.;1                A.B;1
    A.*.B*         A^.DISK.BLOCK;1        A^.C^.B.DAT;1
    A?B.TXT;*      A^.B.TXT;5             A^.^.B.TXT;1
    *.DAT          Lots^.of^.Periods.dat;1DAT.;1
    Mil?no.dat     Milano.dat;1           Millaano.dat;1
    NAPOLI.?.DAT   napoli.q.dat;1         napoli.abc77.dat;1

3.1.6  –  Case Sensitivity and Blindness

    In prior versions of OpenVMS, DCL and RMS converted all
    file specifications to uppercase. When using Extended File
    Specifications, the case of all file names is preserved as
    created by the user.

    Files and directories can have mixed case names in extended file
    names.

    Original
    file name      ODS-2 Volume   ODS-5 Volume

    MILANO;1       MILANO.;1      MILANO.;1
    SanRemo        SANREMO.;1     SanRemo.;1
    genoa..1       GENOA.;1       genoa.;1

3.2  –  Directory Specification Differences

 The following topics describe the deeper directory structures and
 extended naming syntax available with Extended File Specifications.
 It is now possible to go beyond the eight levels of directories
 previously supported in OpenVMS.
    See also the OpenVMS User's Manual and the Guide to OpenVMS File
    Applications for more information about directory specifications
    in Extended File Specifications.

3.2.1  –  Deep Directory Structures

    OpenVMS 7.2 and later supports deep nesting of up to 255
    directories with the restriction that the total directory
    specification must be no longer than 512 8-bit or 16-bit
    characters.

    For example, a user can create the following directories on an
    ODS-2 or ODS-5 volume:

    $ 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]

3.2.2  –  Directory Naming Syntax

    When using Extended File Specifications, directory names conform
    to most of the same conventions as file names when using the
    ISO Latin-1 character set. Periods and special characters may
    be present in the directory name, but they must be preceded by a
    circumflex (^) in order to be recognized as literal characters,
    as shown in the following table:

    CREATE/DIRECTORY. . .       Result

    [Hi^&Bye]                   Hi^&Bye.DIR;1
    [Lots^.Of^.Periods^.In^.ThisLots^.Of^.Periods^.In^.This^
                                .Name.DIR;1

3.2.3  –  Directory ID and File ID Abbreviation

    Under some circumstances, a full file specification may contain
    more characters than the 255 bytes allowed by unmodified
    applications. If a file specification that such an application
    needs exceeds 255 bytes in length, RMS generates a shorter
    file specification by abbreviating the directory to a DID
    abbreviation, and if necessary, the filename to a FID
    abbreviation.

    When the file specification is too long, RMS first attempts to
    generate a shorter directory specification by identifying the
    directory with its directory ID. This shorter specification is
    referred to as a DID abbreviation.

    TEST$ODS5:[5953,9,0]Alghero.TXT;1

    Note that this form of the directory name must have three numbers
    and two commas to avoid ambiguity with UIC format directory
    names. With the DIRECTORY command you can view the shorter
    DID abbreviation version as well as the full version of a file
    specification.

3.3  –  Working in Mixed Environments

    If working in an environment which contains both OpenVMS Alpha
    and OpenVMS VAX systems, it becomes more important to know on
    which type of volume files are being created and on which type of
    volume your default directory resides.

    When accessing an ODS-5 volume, you need to set the parse style
    to EXTENDED to accept and display extended file specifications.
    The default setting is TRADITIONAL. To set the parse style, enter
    the command:

    $ SET PROCESS/PARSE_STYLE=EXTENDED

    When working in a mixed environment of OpenVMS VAX and OpenVMS
    Alpha, it is important for users to realize upon which system
    they are working. OpenVMS 7.2 and later allows VAX systems to
    mount ODS-5 volumes; however users on OpenVMS VAX systems can
    access only files with ODS-2-compliant file names.

    When working in a mixed environment of ODS-2 and ODS-5 volumes,
    keep in mind the restrictions of ODS-2 file names when creating
    files on ODS-5 volumes. If a file is created with special
    characters on an ODS-5 volume, the file must be given an ODS-2
    compliant name if it is copied to an ODS-2 volume.

3.4  –  DCL Command Parameters

    Command procedures that use file names as parameters can produce
    different results in an ODS-5 environment.

    You can switch from the TRADITIONAL to the EXTENDED parse style,
    and this section describes the following areas that may be
    affected if you choose to do so:

    o  Command procedure file specification

    o  Case preservation and $FILE

    o  Ampersand versus apostrophe substitution

3.5  –  Command File Specification

    If indirect command procedures are used, you may need to put
    quotes around file specifications.

    The following examples show the differences in output between
    TRADITIONAL and EXTENDED parse styles when using the same command
    file, SS.COM:

           $ create ss.com
           $ if p1 .nes. "" then write sys$output "p1 = ",p1
           $ if p2 .nes. "" then write sys$output "p2 = ",p2
           $ if p3 .nes. "" then write sys$output "p3 = ",p3

    o  Setting the parse style to an ODS-2 environment and running
       SS.COM, the following output occurs:

              $ set process/parse_style=traditional
              $ @ss ^ p2 p3
              p1 = ^
              p2 = P2
              p3 = P3

       Note that the circumflex (^) is the first argument, and that
       the case is not preserved for the p2 and p3 variables.

    o  Setting the parse style to an ODS-5 environment, the following
       output occurs when running the same command procedure:

              $ set process/parse_style=extended
              $ @ss ^ p2 p3
              p1 = ^ P2
              p2 = P3

       Note that the command procedure recognizes the circumflex (^)
       as the escape character, and "^ P2" is the first argument.

    o  Adding quotes to the circumflex (^) produces the following
       outcome:

              $ @ss "^" p2 p3
              p1 = ^
              p2 = P2
              p3 = P3

       Because the circumflex (^) is within a quoted string, it is
       not treated as an escape character.

    o  Adding quotes to the p3 variable produces the following
       outcome:

              $ @ss "^" p2 "p3"
              p1 = ^
              p2 = P2
              p3 = p3

       Note that the case is preserved for the p3 variable.

    o  In an ODS-2 environment, the following command treats the
       circumflex (^) and the p2 and p3 strings as arguments, and the
       command procedure produces the following results:

              $ set process/parse_style=traditional
              $ @ss^ p2 p3
              p1 = ^
              p2 = P2
              p3 = P3

    o  In an ODS-5 environment, the circumflex (^) is treated as
       the escape character and DCL looks for the file "SS^_P2.COM",
       which results in the following error:

         $ set process/parse_style=extended
         $ @ss^ p2 p3
        %DCL-E-OPENIN, error opening USER$DISK:[TEST]SS^_P2.COM; as input
        -RMS-E-ACC, ACP file access failed
        -SYSTEM-W-BADFILENAME, bad file name syntax

3.5.1  –  Case Preservation and $FILE

    DCL attempts to preserve the casing of file specifications. It
    can do this only for commands defined with the Command Definition
    Utility (CDU). DCL preserves case for any item defined in the
    command definition file (.CLD) with the $FILE parse type.

    Refer to the Command Definition Utility manual for more
    information.

3.5.2  –  Ampersand Versus Apostrophe Substitution

    You can use ampersand (&) substitution as opposed to apostrophe
    substitution, to preserve case during traditional parsing.

    The following traditional parsing example shows a series of
    commands that change the case of a character string:

           $ set process/parse_style=traditional
           $ x = "string"
           $ define y 'x'
           $ sho log y
              "Y" = "STRING" (LNM$PROCESS_TABLE)
           $ define y &x
           %DCL-I-SUPERSEDE, previous value of Y has been superseded
           $ sho log y
              "Y" = "string" (LNM$PROCESS_TABLE)

    Note that the use of the ampersand (&) preserved the case of the
    character string assigned to the x variable.

    Apostrophe substitution takes place before the command line is
    set to uppercase, and ampersand substitution takes place after
    the command line is set to uppercase.

    The following extended parsing example shows the same series of
    commands:

           $ set process/parse_style=extended
           $ define y 'x'
           %DCL-I-SUPERSEDE, previous value of Y has been superseded
           $ sho log y
              "Y" = "string" (LNM$PROCESS_TABLE)
           $ define y &x
           %DCL-I-SUPERSEDE, previous value of Y has been superseded
           $ sho log y
              "Y" = "string" (LNM$PROCESS_TABLE)

    Note that both character strings for the y variable are returned
    lowercase. This happens because the DEFINE command uses $FILE,
    which preserves the case.

    Ampersand substitution can therefore be used to specify EXTENDED
    file names even though the parse style is set to TRADITIONAL, as
    shown in the following example:

    $ set process/parse=extended
    $ cre file^ name.doc
    Contents of an ODS5 file
     Exit

    $ set process/parse=traditional
    $ a = "file^ name.doc"
    $ type file^ name.doc
    %DCL-W-PARMDEL, invalid parameter delimiter - check use of special
        characters
     \^NAME\
    $ type 'a'
    %DCL-W-PARMDEL, invalid parameter delimiter - check use of special
        characters
     \^NAME\
    $ type &a
    Contents of an ODS5 file

                                   NOTE

       Ampersand substitution does not work for foreign commands.

3.6  –  DECwindows Output

    When using a DECwindows DECterm terminal emulator, you must
    select UPSS ISO Latin-1 from the General... submenu on the
    Options menu to display the full ISO Latin-1 character set
    correctly.

    F$EDIT assumes that the setting is 8-Bit Multinational
    Characters, as do many text editors. This can affect the output
    of ODS-5-compliant file specifications.

4  –  Programming

    The following topics describe how to evaluate an application's
    support for Extended File Specifications, and provides guidelines
    for upgrading that support.

4.1  –  Evaluating Support Status

    As part of testing OpenVMS Alpha Version 7.2 (and later),
    OpenVMS application developers should evaluate and test all
    existing applications to determine their current level of support
    for Extended File Specifications and whether that level is
    appropriate.

    Most unmodified OpenVMS applications fall into the default
    support category. Specifically, these applications use the
    traditional NAM block rather than the new NAML block 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 Specifications. However, you can choose to upgrade these
    applications to full support, if necessary.

    However, any applications that are coded to undocumented
    interfaces, or include any of the following may fall into one
    of the no support categories:

    1. Use of 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, valid file names could differ
       between interfaces. (No extended file name support)

                                      NOTE

          All XQP applications that receive file names from the XQP
          and encounter extended file names on a ODS-5 disk will
          see pseudonames returned in place of Unicode (UCS-2) or
          ISO Latin-1 names that are not ODS-2 compliant. This may
          cause applications to act in an unpredictable manner.

    2. Assumptions about the syntax of file specifications, such as
       the placement of delimiters and legal characters. (No extended
       file name support)

    3. Assumptions about the case of file specifications. Mixed
       and lowercase file specifications will not be converted to
       uppercase, which could affect string matching operations. (No
       extended file name support)

    4. Dependence on the traditional directory depth (fewer than 8
       levels). (No extended file name support)

    5. Internal knowledge of the file system, which includes
       knowledge of the contents of a directory and how file header
       data is structured on a disk. (No ODS-5 support)

    You can choose either to modify these applications to support
    Extended File Specifications or not to use them under Extended
    File Specifications.

4.2  –  Upgrading Support

    The following topics describe the changes necessary to upgrade
    the level of support for ODS-5. Note that you must first ensure
    that the application meets the default support level before you
    can upgrade it to the full support level.

                                   NOTE

       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.

4.2.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 the following topics

4.2.2  –  Supporting 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.
    These applications use physical or logical I/O to bypass the
    file system when they access the volume or access directory
    files or other metadata files directly, and therefore must be
    installed with privileges or run by a user who has privileges.
    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.

    Recommendations: Applications should use documented interfaces
    and structures whenever possible.

4.2.3  –  Supporting Long File Names

    If an application does not handle extended names successfully,
    examine the application for any the following:

    o  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.

    o  Does the application attempt to parse or assume knowledge
       of the syntax of a file specification? For example, the
       application might search for a bracket ([) to locate the
       beginning of a directory specification, or for a space
       character to mark the end of a file specification.

       Recommendation: The application should rely on RMS to
       determine whether a file specification is legal rather than
       pretesting the actual name. Use the NAM$L_NODE, NAM$L_DEV,
       NAM$L_DIR, NAM$L_TYPE, and NAM$L_VER fields of the NAM block
       or SYS$FILESCAN to retrieve this information.

    o  Does the application depend on the NAM$V_DIR_LVLS bits in the
       NAM$L_FNB field to determine how many directory levels there
       are in the current file specification? Because there are only
       three bits in this field, it can only specify a maximum of
       eight levels. Applications seldom use these bits; they are
       mainly used by RMS when a NAM is specified as a related file
       specification.

       Recommendation: Starting with OpenVMS Version 7.2, there is
       a new larger field available in both the NAM and the NAML
       blocks, NAM$W_LONG_DIR_LEVELS. Use this field to locate the
       correct number of directory levels.

    o  Does the application rely on the NAM$V_WILD_UFD and SFD1 -
       SFD7 bits to determine where there are wildcard directories?
       Because there are only eight of these bits they can only
       report wildcards in the first eight directory levels.
       Applications seldom use these bits; they are mainly used by
       RMS when a NAM is specified as a related file specification.

       Recommendation: Starting with OpenVMS Version 7.2, there is
       a new field available in both the NAM and NAML block, NAML$W_
       FIRST_WILD_DIR. Use this field to locate the highest directory
       level where a wildcard is to be found.

    o  Does the application use the QIO interface to the file system
       and specify or request a file name from QIO directly? The
       QIO interface requires that an application specify explicitly
       that it understands extended file names before it will accept
       or return the names. In addition, the file name format for
       extended file names is not identical between RMS and the QIO
       interface. Additionally, some file names may be specified in
       2-byte Unicode (UCS-2) characters. Your application must be
       capable of dealing with 1 character that spans 2 bytes.

       Recommendations: Most applications that use the QIO interface
       also use RMS to parse file specifications and retrieve the
       file and directory ID for the file. They then use these ID
       values to access the file with the QIO interface. This method
       of access continues to work with extended names.
       VSI recommends changing to this method to fix problem.

       You can also obtain the name that the QIO system uses from
       the NAML$L_FILESYS_NAME field of a NAML block, or use the new
       system service (SYS$CVT_FILENAME) to convert between the RMS
       and the QIO file name. In this case, you will also need to
       provide an expanded FIB block to the QIO service to specify
       that your application understands extended names, expand your
       buffers to the maximum size, and prepare to deal with 2-byte
       Unicode characters.

4.2.4  –  Upgrading to Full Support

    Some OpenVMS applications, such as system or disk management
    utilities, may require full support for Extended File
    Specifications. Typically these are utilities that must be able
    to view and manipulate all file specifications without DID or
    FID abbreviation. To upgrade an application so that it fully
    supports all the features of Extended File Specifications, do the
    following:

    1. Convert all uses of the RMS NAM block to the new NAML block.

    2. Expand the input and output file name buffers used by RMS.
       To do this, use the NAML long_expanded and long_resultant
       buffer pointers (NAML$L_LONG_EXPAND and NAML$L_LONG_RESULT)
       rather than the short buffer pointers (NAML$L_ESA and NAML$L_
       RSA), and increase the buffer sizes from NAM$C_MAXRSS to
       NAML$C_MAXRSS.

    3. If long file names (greater than 255 bytes) are specified in
       the FAB file name buffer field (FAB$L_FNA), use the NAML long_
       filename buffer field (NAML$L_LONG_FILENAME) instead. If long
       file names are specified in the default FAB name buffer field
       (FAB$L_DNA), use the default NAML name buffer field (NAML$L_
       LONG_DEFNAME) instead.

    4. If you use the LIB$FIND_FILE, LIB$RENAME or LIB$DELETE
       routines, set LIB$M_FIL_LONG_NAMES in the flags argument
       (flags is a new argument to the LIB$DELETE routine). Note
       that you can use the NAML block in place of the NAM block to
       pass information to LIB$FILE_SCAN without additional changes.

    5. If you use the LIB$FID_TO_NAME routine, the descriptor for
       the returned file specification may need to be changed to
       take advantage of the increased maximum allowed of 4095
       (NAML$C_MAXRSS) bytes.

    6. If you use the FDL$CREATE, FDL$GENERATE, FDL$PARSE, or
       FDL$RELEASE routine, you must set FDL$M_LONG_NAMES in the
       flags argument.

    7. Examine the source code for any additional assumptions made
       internally that a file specification is no longer than 255
       8-bit bytes.
Close Help