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