  ODS-2 and ODS-5 Filename Specifications? 
 The Question is:
 
How do I force all users to stay within the file
naming convensions of ODS-2 while retaining the
directory depth of ODS-5 ?
 
 The Answer is :
 
  There is no OpenVMS mechanism provided that will enforce the use of
  ODS-2 syntax upon an ODS-5 volume -- the key word in that sentence
  is "enforce", of course.  This setting is at the discretion of the
  user or the application, and the setting is not a security-relevent
  object and thus a setting cannot be mandated.  Your option: you would
  want to default the parse style to the traditional ODS-2 parsing and
  you would want to periodically scan the volume, using a RENAME or
  other commands as appropriate.
 
  The Advanced Server (PATHWORKS) server does not provide a mechanism
  to restrict an ODS-5 volume to the traditional ODS-2 syntax.
 
  Applications based on ODS-2 are traditionally limited to a maximum of
  sixteen levels of directories, using a concealed rooted logical name
  for the first eight levels.  OpenVMS utilities and mechanisms can thus
  contend with up to sixteen directory levels.
 
  The ODS-2 file system has itself never had a directory depth limit, the
  limit has been in higher-level system and application software.  What
  is and has been limited is the size of various strings that an
  application can use to retrieve the data about a directory path.  As
  part of the ODS-5 work in OpenVMS V7.2 and later, these buffers were
  increased within RMS and the XQP and within BACKUP to accommodate longer
  directory strings.  For example, if a specific application does not have
  a string length capacious enough for the filename (ie: 255 characters,
  better known by the NAM$C_MAXRSS constant) but the directory (or overall
  string) is greater than that, RMS and the XQP will collapse that string
  using what is known as the "DIDing" of file specifications.
 
  Unfortunately for this, the Advanced Server (PATHWORKS) package does not
  support DIDing and FIDing within filenames.
 
 Answer written or last revised on  4-SEP-2002 
