IRLM enhancement in case of global deadlock processing

We had a situation which was described in case TS015567644. The symptom was that IRLM could not fully process the complete deadlock stuff of all members of an 8-way DS system. Therefore we get DXR167E in some of the members. Additional workload with additional deadlock situations were pumped in, so that IRLM could end only some of the deadlock/timeout processes. But due to the pumping in, IRLM could not resolve the deadlocks/timeouts completely. One thread, which might be in the ssstem for hours,  seems to stop the complete processing, because after finding it and cancelling it, all is working fine. Here is the update from the case:

"-Could it happen that one thread at 13:39 was not resolved due to the large dependencies and next time the dependencies have grown and IRLM could again not resolve and so forth until one cancels this thread 2 hours later?

And if: Is this works as designed or will IRLM lab do something for such situations?

On 2/26, we are seeing in the IFC196 trace that the group is doing timeouts during the delay period which suggests that global timeout processing is able to progress. IRLM is working as designed in this situation. The problem appears to be many waiters are continuing to flow in during this period as the customer has suggested, so even though we are timing waiters out, the maxcycles condition can persist due to continuous influx of waiters.

We recommend that they open an AHA idea for the issue, so we can explore design changes in this area."

Therefore the AHA Idea.