Prevent un-necessary Paging Delays when 'freed' CICS storage is reused.

CICS needs to be able to eliminate or reduce the overhead of paging that occurs for pages of private virtual storage that have been released (i.e. EXEC CICS FREEMAINed) to the CICS Storage Manager. Especially costly are Page-Ins from Page Datasets when 'freed' CICS storage is paged out and then later re-used.
.
In general, the CICS Storage manager does 1 z/OS Getmain to get a large chunk of private storage and that storage will never be z/OS Freemain'd. The CICS Storage Manager manages that storage. That is, the CICS Storage Manager subdivides that large chunk and uses pieces of it to satisfy requests for storage from other parts of CICS. And when these other parts of CICS give back these pieces of storage, the CICS Storage Manager keeps track that these pieces are free and can be used to satisfy other requests for storage in the future.
.
This design lends itself to paging issues as described in the following example situation:
.
1) CICSPRD1 starts and getmains from z/OS 1 Gig of high private storage. The storage range of that 1 Gig is from 1D400000 to 5D400000.
2) As CICSPRD1 transactions run and request storage from the CICS Storage Manager and release storage to the CICS Storage Manager, it is the 512 Meg between 1D400000 and 3D400000 that is being used and released and reused frequently. The storage between 3D400000 and 5D400000 hasn't been referenced yet.
3) One morning, some transactions with larger storage needs run and CICS Storage Manager uses the 256 Meg between 3D400000 and 4D400000 for those transactions. Those transactions end and release that 256 Meg back to the CICS Storage Manager.
4) CICSPRD1 transactions continue to use and reuse the 512 Meg between 1D400000 and 3D400000. The 256 Meg between 3D400000 and 4D400000 has not been used again since it was used and released hours ago.
5) During the night, there is a shortage of real frames in the LPAR. RSM chooses to take the real frames backing the 256 Meg from 3D400000 to 4D400000 in CICS This storage is a good candidate for stealing since it hasn't been referenced in many hours. RSM copies the contents of that 256 Meg to page datasets. This is true even though nothing in CICS cares what is on those pages. And RSM gives the real frames to other jobs in the LPAR.
6) CICS storage manager continues to satisfy the storage needs of transactions from the 512 Meg from 1D400000 to 3D400000.
7) The next morning, the transactions with higher storage needs run and CICS Storage Manager needs to give them the 256 Meg from 3D400000 to 4D400000. As that storage is referenced, RSM has to back those virtual pages with real and page-in from the page datasets the contents of those virtual pages. The page-in of several Meg of storage can severely hurt the performance of the CICSPRD1 region for many seconds.
.
In this example, the page-in of the 256 Meg from 3D400000 to 4D400000 is completely unnecessary as the new users of that storage are getting fresh storage and may even clear it before using it. But, of course, RSM doesn't know that since this storage has never been z/OS Freemain'd since it was referenced the first time.
.
If the CICS Storage Manager had known that 256 Meg of just released storage was not going to be re-used for 24 hours, then it would have made lots of sense to do something like a PGSER RELEASE for that storage so that RSM knows it can release all resources backing that storage. Then when the storage is reused 24 hours later, it will have to be re-backed with real frames but there will be no page-in from page datasets.