Hi all,

I have a philosophical question about how the "XLTRIM" concept
should work.

Question:

   *Should* a utility program do an XLTRIM on a file whose EOF is 0?

Background #1: Trimming

   On MPE V, MPE provided a method (via FCLOSE) to let a program
   release all sectors of a file that were "above" the EOF.
   MPEX, and others, provided users the ability to "TRIM" their
   files via this feature.  The side-effect is that the LIMIT is
   reduced down to the current EOF.

   On MPE/iX, MPE still provides that feature, but it added a new
   feature.  FCLOSE can let a program release all pages of a file
   that are "above" the EOF ... *without* changing the LIMIT.
   MPEX, and others, provided users the ability to "XLTRIM"
   their files via this feature.

Background #2: Users

   On MPE/iX, users sometimes do "BUILD AXLDEV1;DEV=1;DISC=xxx,y,y"
   to fully allocate some disk storage for some reason (e.g., to
   ensure that they always have a certain amount of potentially free
   disk space available in the future).  (Yes, Ken N., they do it
   on MPE V as well :)

Background #3: Tools

   MPEX's XLTRIM will throw away that carefully reserved disk space.

   De-Frag/X's TRIM command will not throw it away ... we said "gee,
   if the EOF is exactly 0, then the disk space was manually allocated
   by the user for a reason ... let's preserve it;
   if the EOF is greater than 0, then the extra disk space beyond the
   EOF is probably wasted space ... let's trim it."

   Solution-Soft's trim command: unknown.

   STORE will not backup any pages "above" the EOF.

Problem:

   We have some software that needed an inter-process communication
   area ... a mapped file seemed ideal.  However, we didn't want the
   data to persist across a restart, and we would prefer to save the
   user the cost of storing the data during their backups.

   So...we said, hey...let's just do:
           build foo; rec=128,1,f,binary; disc=1024,2,2
   this builds a file of 1024 * 256 bytes, fully allocated on disk,
   whose EOF is 0 and whose LIMIT is 1024.
   Then, we HPFOPEN it (with long mapped access) and use it.

   Things are fine.   Until a user does an MPEX ALTFILE FOO;XLTRIM
   (while the file is closed) ...that discards the pages beyond
   the EOF.  Since the EOF is 0, that means the entire data area
   is gone.  Poof.

Solutions:

   1) we change our code to set the EOF to the LIMIT.

      This works, of course.

      Drawback: STORE will now backup the entire file :(

      Drawback: other users' use of BUILD to preserve disk space
      isn't free from harm from XLTRIM.

   2) we convince Vesoft (and anyone else implementing XLTRIM)
      that files with EOF = 0 are special, and shouldn't be trimmed.

      Drawback: we still have to do a workaround, because it takes
      time for such changes to get distributed to all users.

Thanks!

--
Stan Sieler                                          [log in to unmask]
                                     http://www.allegro.com/sieler.html