Improved LATCH when index splitting

[Current Product & Version]
-Db2 12 for z/OS
-IBM Tivoli OMEGAMON XE for DB2Performance Expert on z/OS v5.5
-z/OS v2.3
-WebSphere Application Server v9 for z/OS

[Environment]
Data sharing in three-way sysplex environment

[Problem]
Our customer is using WAS for z/OS and DB2 for z/OS on their mission critical system.
Several times our customers experienced slow transaction responsiveness and timeouts, severely impacting their business.
I opened CASE(TS013070610/TS013085686）to resolve this problem, but these CASEs does not identify the cause of the problem and does not currently resolve the problem.

This CASE explained that some read thread held S page latch waiting, it could cause the index split thread to wait on the page latch, so many transactions became wait or time out.
Unfortunately, it was not possible to identify the read thread holding S-LATCH for a long time from materials such as Db2 logs.

As a side note, obtaining SLIP dumps using SLIP traps is not acceptable due to concerns about reduced transaction response.
We believe that product improvements are necessary to identify the cause of this problem.

[Workaround(Bypass)]
none

[Proposal/Idea]
If a page in an index split is a higher level page, LATCH will be held for all related lower level pages.
In that case, there is a concern that the number of transactions that will be affected will increase, leading to an increase in the number of transactions that will result in poor response.

When an index split occurs, instead of holding LATCH until the latch locks on all pages are released, reduce the range of pages that hold LATCH sequentially and improve it so that fewer transactions are affected by waiting for LATCH.

[Benefits/Value]
Our customers can identify the cause of this problem, consider a solution, and expect normal and stable business operations.