CAS9 not cleaning up CSA upon completion leaving orphaned storage

Products

• COMMON SERVICES FOR Z/OS

Issue/Introduction

Following an IPL of the system, after CAS9 executes successfully, it is not cleaning up CSA.

Looking in the Common Storage Remaining (CSR) display of SDSF and drilling down on the display you still see a large amount of common storage (CS) that is orphaned by each run of CAS9.

Resolution

This is normal and CAS9 is working as designed. The purpose of CAS9 is to load into CSA/ECSA (as required) the necessary modules and control blocks for the CAIRIM infrastructure used by Broadcom products. It serves as an "anchor point' for other CA products to use.  Additionally(based on INIT statements) it will load some product infrastructure modules/control blocks. This environment will remain resident for the extent of the IPL. Since CAS9 ends, this storage is marked "orphan", but is necessary for the proper execution of Broadcom products. Any attempt to clean it up will result in unpredictable results either by Common Services itself and/or any other CA Product or solution that requires the use of this CSA.

Any use of CSA  is based on the execution requirements of z/OS in regards to the service we are extending or exploiting. We are always looking for changes in z/OS that will allow us to move modules or control blocks to ECSA.

Additional Information

CCS 15.0 environments:

To provide performance improvements in environments that have a high volume of SMF activity, CAS9 pre-allocates a pool of storage needed for our processing.  Because some SMF processing occurs in 24bit mode, the pool is in CSA. Once the pool is allocated, it will not be freed, it remains for the extent of the IPL. If you are CSA constrained, and you are running with CCS 15.0 PTF LU05527, then PTF LU14303 provides support for CAS9 parameter CPOOL=NO.

With CPOOL=NO, this pool is not allocated saving approximately 100K of CSA.  This parameter would need to be in the first CAS9 execution after IPL.