  File Fragmentation and Extension Headers? 
 The Question is:
 
I have a large RMS file that is Fragmented. Using a product called Perfect disk
 it states the file has over 1,400 fragments.  The size of the file is
 23,617,385M blocks. If I dump the header information it states: the value of
 154 for "Map areas in use".
I Remember reading many years ago something about the INDEXF.SYS and value of
 155 giving error message about "no more files can be added to the disk."
 
Was this a pre V6 problem? Are the values for the map areas in use still in
 range of (9 - 155)? The reason this file never gets defragmented it is opened
 24*7*365
 
Regards
 
Mark
 
 
 The Answer is:
 
  Your recollection of around the INDEXF.SYS is correct.  It is true that
  INDEXF.SYS is limited to a single file header, which makes the map area
  word limit of 155 significant. This is also true of pagefiles, swapfiles
  and system dump files.  It is NOT relevant to any other file types.
 
  When the map area in the header of a "normal" file fills up, OpenVMS
  allocates an extension header in which new extent pointers are stored.
  You can follow the chain of extension headers using DUMP/HEADER/BLOCK=COUNT:0
  Note the "Extension file identification:" field.  DUMP will also display
  the extension headers all along the chain. Since each header can contain
  between 50 and 70 extents, your file with 1400 extents will comprise
  somewhere between 20 and 30 extension headers, assuming no other attributes
  that consume header space (eg: ACLs).
 
  You can continue to add extension headers until you run out of disk space
  or file headers.  The file will continue to *work* correctly, but it may
  suffer in performance. To find a specific block, the system may need to
  walk the extension header chain sequentially.
 
  The OpenVMS Wizard once observed an RMS indexed file in which the root
  bucket, originally contained in an extent pointed to from the first header,
  had been split. The overflow bucket was allocated to an extent pointed to
  from an extension header some 50 or so headers down the chain.  The I/O
  performance for this file was unsurprisingly rather dismal.
 
  If this file is regularly accessed in an environment where performance is
  critical, the OpenVMS Wizard would recommend this file be CONVERTed on a disk
  with excess contiguous free space, and with generous RMS ALLOCATION and
  EXTENSION values for all file areas.  This will help keep the file, if not
  contiguous, at least in a single file header.   If this file is not
  performance-sensitive -- it is a log file, for example -- it is harmless.
 
  The OpenVMS Wizard would also use DFU (Freeware) or a similar tool to
  evaluate the fragmentation level of of the volume, and would use BACKUP
  or other tool to defragment it as needed.  Further, an investigation of
  the settings of the initial file allocation and file extension sizes
  are definitely warranted.  These settings are available on a process,
  file, volume, and system-wide basis.
 
