Enhance high availability for partition by growth tablespaces.

Real-life scenario is described in the first paragraph below. I included a subset of it.

The issue resulted in critical system outage caused a partition by growth dataset that hit max extents prior to hitting the DSMAX for the partition tablespace size. If this does happen currently the PBG space search algorithm will attempt to extend the dataset at max extents and fail and then, instead of going to the next partition for the insert, Db2 will then start to scan the target partition looking for space. After that search ends Db2 will finally insert the new row into the target partition. While this search is happening, many other transactions were backed up waiting on the partition lock to also attempt to extend the dataset. In our case this pattern repeated itself thousands of times per minute and the result was most transactions timing out and five CICS regions hitting max transactions. The LPAR quickly went up to 100% busy and all applications in that LPAR also either slowed down or started timing out. The next day both the CTO and CEO of our company were aware of this issue as we had to report it to the regulators due to the wide-ranging impact of the problem. As you can imagine it was very difficult to explain how on partition of a Db2 tablespace hitting max extents resulted in an outage of this magnitude. When we then explained how Db2 reacted to the max partition condition they could not understand why the product would behave this way. The number of users and customers impacted were most likely in the thousands. The outage lasted four hours and 30 minutes and was only resolved changing the problem partition to read only after shutting down all of the CICS regions and then doing a reorg to fix the extent problem.