Stan wrote << The current released method is the first phase of allowing per-database (or possibly per-dataset) configuration. We currently say: Search the primary area for up to N blocks and up to K percent of the primary area. If we don't find a hole before either of those limits, we'll use the expansion area. At present, N is 40, and K is 10%. These values seemed like a good compromise. We're not searching the entire primary area, but we're giving secondaries some chance to be clustered near their primary entry. Now...if we make them configurable, setting either to 0 would mean "always use expansion area". SS >> Thanks Stan, The implementation you describe is more reasonable but doesn't seem to match the documentation. ( I've never been guilty of this, not!:) I guess the bottom line is that master capacities are changed more often for performance reasons than for actual capacity reasons. Most applications/datasets, (except for those that take control of record placement) attempt to keep fill factor of about %30 free entries. Although MDX is good insurance in case entries are added for some unexpected reasons. The startling fact is that for master intensive application designs, about one third of everything (disc, backups, and memory content) is zeros! A setting to "always use expansion area" and the associated decrease in the free entry requirements, would certainly result in a significant performance gain for a serial read of a master and backup/ recovery times (if not using host compression). I'm certainly looking forward to 6.0 and doing some performance tests. Mike Hornsby [log in to unmask]