In article <[log in to unmask]>, Therm-O-Link
<[log in to unmask]> writes
>Okay, here's a question for all you Image gurus out there:
>
>We have a detail data set that can get fairly full (like 90+%)
>before the end of the month.  At the end of the month we move
>a lot of the records from this set to another data set that
>serves as the history.  We're not talking about a large
>amount of records.  Detail_Set_1 has a capacity of 18,425
>and 16,657 records, of which 13,223 records will be moved to
>Detail_Set_2, so the percent full will go from 90.4% to
>18.6%.  Detail_Set_1 has records being constantly added
>to it, and then we delete a bunch out during month-end
>processing.
>
>My question is this:  What kind of effect (performance-wise)
>does this have on data base access?  Will DBPUT's to
>Detail_Set_1 take a performance hit because of the long
>delete chain?  What about chain pointers and such?  Are
>they being affected by this process? Is there anything
>I can do with "normal" processing (that is, anything that
>does not require exclusive access to the data base/set)
>to help things out?
>
Delete/archive 'backwards' on the move to Detail Set 2?

If I start with an empty, brand new Detail Set 1, disk sectors 1-2-3-4-5
and I DBPUT to them, my record chain goes A-B-C-D-E on sectors 1-2-3-4-5
which is in line.

And if I delete them A-B-C-D-E, then the delete chain is 1-2-3-4-5, and
this is the most efficient Delete.

But the next few DBPUTs F-G-H-K-J consume the delete chain from 5
downwards, so my sectors 1-2-3-4-5 now hold J-K-H-G-F. Backwards!

But it comes out straight next period.
So do you get alternating 'slow' and 'fast' months with this app? :-)

If you delete backwards (Mode 6 down a chain instead of 5), you write
your delete chain 5-4-3-2-1, so your DBPUTs always come out 1-2-3-4-5.

Mind you, if you only write stuff during the month and then archive it,
without reading it much, you could spend more time on the backward
delete, and backward free chain consumption, than you saved on read
access... needs some quick calculations.

Another trick I considered for you is to set HWMPUT on, so you would
always be DBPUTting into 'fresh space' until the set was full, even if
there was a delete chain. However, with 16k out of 18k used before you
delete, this would not buy you anything.

Seems to me the free space chain would be better if it worked like a
message file, being consumed from the bottom end, but written at the
high end. But it isn't. Ah well. :-(
--
Roy Brown               Phone : (01684) 291710     Fax : (01684) 291712
Affirm Ltd              Email : [log in to unmask]
The Great Barn, Mill St 'Have nothing on your systems that you do not
TEWKESBURY GL20 5SB (UK) know to be useful, or believe to be beautiful.'