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

Article Id: 33621

Status: Published

Updated On: 14-02-2018 08:19

Legacy Id: TEC1400931

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: