----------------------------<snip>--------------------
If performance of a frequently-updated, on-line KSDS file is your major
concern, I would recommend experimenting with various values of CA free
space to keep CA splits low, but leaving no CI free space. Allow those
areas of the file undergoing inserts to do CI splits as necessary,
producing underutilized CIs; then these updated areas of the file will
utilize the available CA free space, making it unlikely that a CI split
will force a high-overhead CA split. That way only those portions of
the file that have to be updated will see degraded I/O throughput from
having fewer records per CI, rather than incurring that overhead on all
CIs by leaving CI free space.
----------------------------<unsnip>-----------------------
You might also want to consider using "Sequential Insert Strategy",
wherein CI splits occur always at the point of insertion, rather than
letting the split occur as close as possible to the center of the CI. If
the keys of the insertions are such that insertions occur in "clusters"
around a specific point, SIS might very well be to your advantage. YMMV.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
