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.