VMS Help  —  Ext File Specs, 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

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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

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

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.

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]

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

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

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

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

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.

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.

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.
Close Help