ENF is using a large amount of ECSA, how can I get ECSA to release it?

book

Article ID: 33621

calendar_today

Updated On:

Products

CA ACF2 CA ACF2 - DB2 Option CA ACF2 for zVM CA ACF2 - z/OS CA ACF2 - MISC CA CIS CA Common Services for z/OS CA 90s Services CA Database Management Solutions for DB2 for z/OS CA Common Product Services Component CA Common Services CA Datacom/AD CA ecoMeter Server Component FOC CA Easytrieve Report Generator for Common Services CA Infocai Maintenance CA IPC Unicenter CA-JCLCheck Common Component CA Mainframe VM Product Manager CA Chorus Software Manager CA On Demand Portal CA Service Desk Manager - Unified Self Service CA PAM Client for Linux for zSeries CA Mainframe Connector for Linux on System z CA Graphical Management Interface CA Web Administrator for Top Secret CA CA- Xpertware CA Compress Data Compression for MVS CA Compress Data Compression for Fujitsu CA PanApt CA PanAudit

Issue/Introduction

Problem:

We are having an ECSA issue. I see that ENF is taking up a bit of it. I cycled ENF (to increase database size), but it is still holding ECSA.  How do I get ENF to release the ECSA memory?

 

Environment: 

CA COMMON SERVICES 14.1 S1401, z/OS 2.1

ENF starting the ENFUSS component

 

Cause:

15.09.06 STC00042 CAS9214I - CA-ENF Command: DCM(CARRDCM0) * UNIX SYSTEM SERVICES INTERC 
15.09.06 STC00042 CAS9240I - DCM - Command complete 
15.09.06 STC00042 CAS9214I - CA-ENF Command: DCM(J163DCM0) * ACF2 
15.09.06 STC00042 CAS9240I - DCM - Command complete 
15.09.07 STC00042 CARR001I - CA Intercept Technology for z/OS UNIX Services starting 
15.09.07 STC00042 CARR051I - Restart underway - reloading resident modules 
15.09.08 STC00042 CARR029I - 090 USS probes now active 
15.09.08 STC00042 CARR002I - CA Intercept Technology for z/OS USS initialized, RC=0000 

 ENFUSS uses CSA/ECSA and will not release it during the duration of the IPL.   

 

Resolution:

·         Simply recycling ENF without an IPL will not release the allocated storage

·         In order to reclaim the storage:

o   Comment out the following DCMs:

§  The ENFUSS DCM CARRDCM0

§  The ACF2 USS DCM J163DCM0

o   Re IPL to prevent ENFUSS from initializing

Additional Information:

The CA COMMON SERVICES for z/OS r14.1 ADMINISTRATION GUIDE

The CA COMMON SERVICES for z/OS r14.1 INSTALLATION GUIDE

The CA COMMON SERVICES FOR z/OS DOCUMENTATION WIKI

The CA ACF2 FOR z/OS r15 INSTALLATION GUIDE

Support.ca.com is a great tool for searches. 

In this case (once signed on), a Knowledge Base Search gets right to the point (of answering your CSA/CAS9 concern).... 

Using keywords like cas9 storage (also used orphaned), I come up with: 

ID: FAQ262926 It appears that CAS9 is orphaning storage. Is this normal 
Question: It appears that CAS9 is orphaning storage. Is this normal? 

Answer: Although it may appear that CAS9 has orphaned storage, this is not 
the case. Because CAS9 is not a long running task, any storage used for 
resident modules, loaded via the services provided by CAS9 (CAIRIM) will 
appear as being orphaned. As a general guideline, CAS9 (CAIRIM, CA LMP, 
CAISSF) requires approximately 9K CSA and 34K ECSA. Additional CSA 
requirements for resident modules vary with each service or product. Consult your 
solution's installation on documentation for additional solution-specific 
information. 

The biggest offender of ECSA (may not be a problem, but just a fact) is CA-1. 
CA-7 is another, CA SCHEDULER. 

If a client wants to pursue ECSA issues with these CA solutions, new calls would need to be opened (with each product group).   

Environment

Release: ACF2..001AO-15-ACF2
Component: