PM88804 – DISCARDDATA of real frames in z/OS was being done despite no thresholds being hit
This APAR has to do with the REALSTORAGE_MANAGEMENT in DB2 10. The default is AUTO,
meaning thread storage in the pools is cleaned and real frames freed-up after so many commits, or thread deallocation,
as well as if real storage is being stressed on the LPAR with massive paging to AUX.
After this APAR DB2 will free the storage in its pools for other threads, but not release it back to z/OS or UNBACK the frames.
The net effect is a CPU savings at the expense of DB2 using a bit more real storage. There is more verbiage about when any difference
could be seen in the APAR.
From the APAR text....
"When threads terminate, their pool storage may either be
completely freed if the thread is not cached for reuse, or a
portion may be freed. In either case, storage which is only
virtually freed by DB2 since it is submanaged, will have its
REAL frames unbacked in many cases. This unbacking requires RSM
latch serialization and also results in a pagefault when those
pages are again used. This whole process can show significant
CPU usage depending on the number of threads and their