Additional ZRECP LONG support to avoid long running behavior when Long Chain Detection thresholds are set too low

Recently during a system outage a Recoup was necessary to validate the integrity of our Database once the system was back up. As part of normal Recoup procedures a ZRECP LONG display entry is made to view logs of DF Files that contain subfiles that have exceeded their long chain detection threshold.

Unrelated to the system outage, it was found that one of our DF files did contain over 3 Million subfiles that exceeded the long chain detection threshold put in place.

When doing ZRECP LONG or ZRECP LONG SUM against a long chain log that contains this many items, it has been observed that BRCD (long chain display program) can take hours before any response is received back to the console due to a sort that is conducted against all items in the long chain log.

This is of course a tuning problem with the Long Chain detection threshold we have set and can be remediated by increasing the threshold. However, there really isnt any support in place currently to quickly identify that we may need to increase our detection thresholds outside of observing the long running BRCD behavior.

Possible solutions to address our concerns that have already been discussed with IBM:

1. Providing a user defined cap on how many Long Chain items are tracked in the log file.

2. Potentially avoiding sorting logic on ZRECP LONG SUM displays.