<<Your statements about detpack/reorg trashing the chronological sequence
of a chain need to be amended.  If the chronological sequence is on the
primary path (and it should be if it isn't) then the statement is false.
 I have a bit of experience in these matters.  I wrote the high-speed
detail dataset reorganization function which is in one of the main
database utilities.  I designed it so it would preserve the chronological
integrity.  Actually, it would have been more difficult to design it to
do otherwise using the method I chose.>>


I'm not sure what you mean by "(and it should be if it isn't)"; a detail
set may have a number of paths, any one or more of which may have a
chronological sort on it. We have sets that meet your "it should be"
proclamation, but we also have a number of detail sets where there are
date-sorted chains that are not the primary path; the primary path in
some of them is not sorted at all, and in others it is sorted by some
other non-date-sequence item.

<<All this to say that whilst it may be changing pointers (it has to), it
keeps the sequence in which it finds the entry.  Trust me, I spent years
on that stuff.  A detail dataset reorganization will beat your machine
and exercise the disk drives, but it will not change the chronological
order.  At least not the way I designed it.  What has happened to it
since I left, Lord only knows, but that is how it was then.

Now, if your utility reads the detail dataset serially and then sorts the
entries by primary path and finally loads a new dataset with the output
of the sort, indeed kiss your chronological sequence good bye. This is
not the way I did things, do this one is much more simple and more of the
brute force approach.>>


Exactly; any given database utility or home-grown tool may or may not go
to the trouble to preserve the chronological sequence of all paths, of
the primary path, or of any path at all. Likewise, moving an entry from
one path to another and later returning it to the original path will
destroy the chronological relationship it had with its original
neighbors. Thus my statement that, if you want to guarantee the
preservation of chronological sequence on a path, sort it.

<<Now I have a question.  I read Gary Groves post.  Is there indeed a
demand for on-line reorganization of a detail dataset or is Gary alone in
this?  If there is a demand, about 4 years ago I designed, but never
wrote, a utility which would do just that.  If there is interest, I might
post the strategy on this list and perhaps someone else might pick it
up.>>


Just as dedicated take-over-the-machine disk defragmentation is giving
way to on-line do-it-in-the-background operations because people can't
afford to take the machine off-line for the time required, I suspect that
demand for on-line on-the-fly optimization of our databases is going to
grow.

Steve