Recoup chain chase needs to handle wide/shallow databases

Recoup congestion on IRART CORHC when chain chasing wide/shallow databases caps recoup's ability to run at the MAX
ECB rate defined and means there is no way to manage or improve chain chase runtimes. The congestion on the IRART is due to the fact that the chain chase design assumes each ordinal will have pools to chain chase. When there are no pools, the only time in between getting the IRARTand releasing the IRART is the time that it takes to retrieve the fixed record. Due to the less time spent chasing pool chains, a significant number of the ECBs will be waiting on the corhc() resource; contention exists. More ECBs does not help in this case. Adding ECBs simply adds to the back log of ECBs waiting to get the corhc() resource.

The recoup design needs to fully accommodate wide/shallow databases so that the operational means of controlling recoup runtimes based on the number of ECBs permitted to run chain chase is effective for all database types.

Today, Recoup chain chase processing assigns one fixed file ordinal number to a single IRART entry. One means of accommodating wide/shallow database would be to modify Recoup to have multiple fixed file ordinals assigned to one IRART entry. This would reduce overhead of managing the IRART entry. A DBDEF parameter should be provided to control the number of fixed file ordinals processed.