Following up on a question by Gary Jackson <[log in to unmask]>,
Phil Anthony <[log in to unmask]> wrote:

>I would think that the high-water mark would stay the same, but the
>delete chain would be really, really long.  You can repack or reload the
>data set to lower the high-water mark.

...

>> How do you reset the HWM on an empty dataset?  Erase it?


There are some other VERY subtle issues having to do with detail datasets,
their HighWaterMark, their FreeEntryCount, and -- last but not least --
their FreeEntry *LIST* (or delete chain).  Further knowledge of these
issues might be of interest to the followers of this thread (bits-and-bytes
folks as well as management folks).

I did a quick scan of my Adager Lab log book and, surrounded by electronic
cobwebs, I found some notes from the late 1970s, when I was actively
reverse-engineering the root file and the dataset structures to be able to
write the low-level bits-and-bytes Adager procedures I needed.

It turns out that if you delete ALL the entries of a detail dataset (via
QUERY or via applications), the HighWaterMark is reset to zero, the
FreeEntryCount is reset to the current capacity, and the FreeEntryList
*HEAD* is reset to 0.  So far, so good.  What's not obvious is that the
FreeEntry *LIST* itself remains unchanged ABOVE the HighWaterMark, with all
of its pointers intact.  If IMAGE actually took the time to go around
zeroing out all of the FreeEntryList *POINTERS*, users would (very
unhappily) discover that the LAST DBDELETE on a detail dataset would take a
monumentally long time (particularly if you are a typical high-end Adager
user with several hundred million entries).

There are some nasty consequences of this.  In particular, if the
FreeEntryList gets corrupted (either the HEAD or any of the POINTERS), it
may so happen that the old (by now CADAVER) FreeEntryList gets incorporated
into the CURRENT FreeEntryList.  I don't need to tell you that this may
eventually lead to DBPUT placing NEW entries ABOVE the HighWaterMark, which
would be totally out of reach for standadr non-privileged programs (such as
QUERY and your applications) and, even worse, might get over-written by new
entries as the HighWaterMark grows...  Quite horrible, indeed!

In the past, IMAGE did not check for this.  I haven't played with the issue
for a long time, so I don't know whether DBPUT now checks before attempting
to place the entry above the HighWaterMark.  Perhaps the IMAGE Lab can
share some info on the current state of affairs.  What I know is that, at
least since the early 1980s, Adager's SetErase function zeroes the old
FreeEntryList and Adager's DetPack function brings everything in line.


Ah...  It's been so long since I worked on these issues.  I guess I am a
nostalgia buff :-)


 _______________
|               |
|               |
|            r  |  Alfredo              mailto:[log in to unmask]
|          e    |                           http://www.adager.com
|        g      |  F. Alfredo Rego               Tel 208 726-9100
|      a        |  Manager, R & D Labs           Fax 208 726-2822
|    d          |  Adager Corporation
|  A            |  Sun Valley, Idaho 83353-3000            U.S.A.
|               |
|_______________|