Re:
> PLEASE DON'T TRY ANY OF THE EARLIER SUGGESTIONS ON THIS THREAD! They will
> meet with the same end.
> You must purge files in reverse alphabetical order. You can do this by

Good...I was hoping someone else would have posted the right answer
before I did!  Thanks, Craig!

Now...
> Your system abort (probably a 2200) stems from the fact that the system is
> trying desperately to make sure that all the changes to your directory are

I suggested a solution for this a couple of years ago ... perhaps before
the problem was on management's "radar screen" :)
I haven't heard if my suggestion was being worked on, so...here it is again...

Basically...as Craig points out,

> On MPE, directories are actually just special files with records for each
> other file or directory that is contained in them. They stored in sorted
> alphabetical order, with the disk address of the file label for that file.
...
> Because we must keep this list of files in alphabetical order, if you add or

The reason for the alpahetical order is that a file-search can be done
quickly via a binary search.

My proposal was:

   At file deletion time:

       If directory size is "small" (say, 1/2 MB), use the original code;

       otherwise:

           while more left to do:

               move "down" a chunk of, say, 1/2 MB (instead of moving down
               the rest of the directory file's contents)
               (each move is a single XM transaction)

               (if this is the last chunk, more_left_to_do := false)
                and zero the now unused final entry, updating info about
                the directory file's "EOF")

   The drawback is that until all chunks are moved down, there will appear
   to be two entries with the same name (the last entry of one chunk
   and the entry that it had just occupied).

   BUT, there must *already* be locking code in place, to prevent
   a searcher from searching during a current-style delete, so we don't
   have to worry about simultaneous access.

   What we have to worry about is a system failure ... because each chunk
   move is a separate transaction.  (Thus, a system failure could leave us
   in a state where 2 of the 4 chunks were moved down, resulting in an
   apparent duplicate entry in the middle of the directory.)

   That necessitates a change in the file search code:

      do binary search as before;

      if entry found, then CHECK THE PRIOR ENTRY FOR A FILE WITH THE SAME NAME,
      (or, check the NEXT entry for a file of the same name, depending upon
      how your binary search is implemented)

      If found, then either:

         - we're doing a directory deletion right now (but, we excluded
           that possibility above, by assuming proper locking strategy,
           so this won't happen!);

      or
         - a prior directory deletion operation failed in the middle

           ...finish the incomplete "purge" (release the read-lock on the
           directory, get a write-lock, re-find the entry (just in case),
           and delete the higher of the two duplicate entries as if it were
           a normal directory entry deletion).

In short, it seems like it shouldn't be too difficult to fix this problem.

Stan Sieler                                           [log in to unmask]
www.allegro.com/sieler/wanted/index.html          www.allegro.com/sieler

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *