What are some common factors that can lead to a CAIENF database space problem and how can it be avoided?

Document ID : KB000030162
Last Modified Date : 09/03/2018
Show Technical Document Details


CA Common Services customers have occasionally had problems with the ENF MUF running short of space while recording events. When this occurs, ENF will display messages from both CA Datacom and CA Common Services indicating an "X37" abend and that the table is full. This document is provided to help provide a solution.

While recording events for various CA Solutions, the ENF MUF can possibly run out of space.  When this occurs, ENF will display messages from CA Datacom and CA Common Services for z/OS indicating an "X37" abend and that the table is full.



One obvious factor is that there was not enough space allocated when the database was defined.  The CA Common Services for z/OS r14.1 Installation Guide, found at either the CA Common Services r14.1 wiki or the CA Common Services for z/OS r14.1 Bookshelf, suggests a formula to approximate the space needed based upon the number of currently recorded events.  From personal experience we find the formula to be too conservative in space.  The formula is found within the “Install Datacom/AD” chapter beneath the heading “Customize a New Datacom/AD for CAIENF”. What we recommend is for our customers to start with a ENF700 file of 300CYLS and a IXX700 file of 100CYLS. Once the product is running in a production environment, Datacom utilities can be run to monitor space usage. Depending on the results the database files can be adjusted either upward or downward by shutting down and reallocating the files. Should an existing database need to be resized and if you wish to preserve the existing recorded events, please refer to technical document TEC544771.  This technical document details the steps to backup the existing data, create a larger database, possibly using the formula previously mentioned, and reload the original data into the newly defined database. Although the document does refer to CA Common Services for z/OS r12.0, the procedure pertains to r14.1 as well.  When the database does run out of space, messages similar to the following can be found in the ENF joblog: 




CAS9316E – STEPTERM “Insert  “ failed – rc(-258) r/s (X’F5F7E2F0F6).


*CAS9208E –  CA-ENF DB:  DB Insert error SQLCODE=-258  SQLSTATE=57S06

CAS9303E – Event STEPTERM no longer recorded due to DB error 0008


The ENF parms themselves are instrumental in preventing space problems as well.  They are designed to keep the Datacom MUF as a self-sustaining entity; regularly cleaning up the database when the recorded events are no longer needed by the CA solutions that use them.  There are five parms that work in conjunction with each other to accomplish this goal.  A detailed description of each is found in the CA Common Services r14.1 Reference Guide under the “CAIENF Control Options”. 

These parms are: 





The first form of the parm is based upon a time using the 24 hour clock.  The default is ARCHIVE(0100) which would case the archive to take place at 1:00 am daily. The recommended best practice is to set a specific time for the archive process to run. Defining AUTO is not the recommended best practice.

The second form will perform the archive when the database reaches 80% (the default) of capacity.  The archive will also be run only once per day.

It is possible that no records will be archived unless the defined retention period for recorded events has been reached.

The other parms pertain to the individual recorded events themselves and work in concert with the ARCHIVE to determine when these recorded events are archived.  For each recorded event, there are 4 parms necessary to achieve this goal.  Using the above mentioned “STEPTERM” event as an example, the parms needed to record this event and also maintain the database are:


EVENT(STEPTERM,ACT)             – Enables the STEPTERM event

EVENT(STEPTERM,REC)             – Requests that the STEPTERM data be recorded to the database

EVENT(STEPTERM,RP=nn)         – The number of days the STEPTERM records will be retained on the database

EVENT(STEPTERM,PURGE=Y)    – Purge the STEPTERM records only when the RP value has been met


With these parms, ENF can prevent the database from filling up by performing the archive on a daily basis and purging eligible records when the RP (retention period) value is reached, The parms prevent the necessity for any type of user intervention and preserves the self-sustainability of the database itself.

If you do not specify PURGE=Y for each recorded event, when the retention period is reached the expired events will be written to a backup file as well as being deleted from the database. If you have a desire to write expired records to a backup file you will want to define these additional control parms to handle the location and name of the backup file:









Please refer to the CA Common Services Reference Guide for these ENF control options.



If you run into a situation where the database fills and can no longer expand automatically, short of allocating a new database you can try to dynamically purge events. This is done using the ENF PURGE console command. Taking the above STEPTERM event as an example, the command would be entered in one of the following formats at the console:




Generally you want to purge the event with the greatest number of recorded records. This can be determined by running a Datacom CXX report for DBID=700. Keep in mind that the event may not record after clearing out some space, particularly if it was disabled as shown in the above CAS9303E message. To enable event recording to take place, enter one of the following commands:



Please Update This Required Field