CAS9 is holding excessive amount of CSA

Products

• Common Components and Services for z/OS

Issue/Introduction

An IPL was executed to activate Common Services maintenance. You now notice additional CSA is being consumed (compared with the previous IPL) as flagged by IBM health check VSM_CSA_THRESHOLD

Environment

Release : 15.0
Component : Resource Initialization Manager

Cause

The increase in CSA usage can be attributed to fix LU05527,  which provides performance improvements to CCS SMF processing. We later identified a calculation error that resulted in more CSA usage than originally thought. Rather than ~130K increase, customers have reported seeing an increase of ~240K.  A new PTF has been released to correct this problem and reduces CSA increase to the expected value.

Resolution

PTF LU08112 is available to resolve this problem.

Additional Information

• If your system cannot support the ~130K increase in CSA usage, a new parameter (CPOOL=NO|YES) has been introduced with PTF LU14303
  • This new parameter can be utilized by modifying the CAIRIM parmlib member.

***NOTE*** This PTF was PE'd. The corrective fixes are LU14882 and LU17029

• Do not code multiple INIT(CAS9INIT) statements in the CARIM parameter members as shown below as this will cause "orphaned" modules in common storage

PRODUCT(CAIRIM) VERSION(CAS9) INIT(CAS9INIT)
PRODUCT(CAIRIM) VERSION(CAS9) INIT(CAS9INIT) PARM(REFRESH(SSF,MB838,LMP))

The statement containing the PARM(REFRESH(xxx)) should only be used to dynamically replace the related modules as a result of applying maintenance and following the implementation instructions provided in a PTFs HOLDDATA statement. This "REFRESH" statement should not be defined when CAS9 executes during a normal IPL process.