Roy writes:

> In message <[log in to unmask]>, Steve Belkacem
> <[log in to unmask]> writes
> >We have two identical image databases, one with data
> >and one empty.
> >
> >Data is extracted from a detail, unsorted dataset with
> >only one path to a master dataset to a flat data file
> >(we have tried extracting using query, cobol image get
> >mode 2, quiz and suprtool). This data in this file is
> >then put (by cobol/image) serially back on to the new
> >empty database.
> >
> >When the new database is then accessed the records are
> >not actually in the same order as on the original
> >database.

<snip>

> Your empty database may be empty of records, but it probably
> 'carries the reminder of every hit that wrote its bytes
>   and cut then, as deleted, to its hidden free space chain
>   it was leaving, it was leaving, but the blighters still remain'....
>
> So the records you add won't necessarily be added from record 0 in the
> detail dataset onwards - the free space chain will be consumed first.
>
> But the serial read *will* be in record number order.
>
> If you delete and recreate your empty database each time, you will start
> with an empty free space chain, and so the records will be written in
> the record number order in which you add them.
>

Actually the "problem" is occurring on the extract side of this procedure.
The records are being read serially from, as Roy pointed out, a dataset that
utilized the free space chain. Recently added records will be somewhere on
the delete space chain, taking the place of records that have been delete,
rather than at the high-water mark. Hence, the records are out of
chronological order as they are unloaded. So the issue *is* the delete space
chain. But it's the delete space chain in the source not the target.

A way to get the two datasets in the same order would be to run an Adager
Detail Repack (or the equivalent detail dataset re-org using the database
utility of your choosing) against the dataset in the source database prior
to serially unloading it. This would repack the entries, preserve the
chronological order of the chains, and remove the delete space chain. Then
when you populate the second database the records should be in the same
order for both serially and chained access.

Unloading the dataset by chains read would keep each individual chain in
chronological order but would be painfully slow compared to a serial read.
The detail repack method would have the added benefit of ongoing performance
improvements for chained access.

Doug.

Doug Werth                             Beechglen Development Inc.
[log in to unmask]                               Cincinnati, Ohio

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