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 : 22/06/2018
Show Technical Document Details
Introduction:
  • The CA Common Services for z/OS ENF component may be used to record events for various CA products. 
    • CA products such as CA-7, Scheduler, CA-11, etc may require event recording
  • ENF writes these events to a Datacom/AD MUF exclusive to ENF
  • Occasionally, the ENF MUF will run short of space
    • ENF will display messages from both CA Datacom and CA Common Services indicating an "X37" abend and that the table is full
    • The X37 abend will generate messages like the following (using an event named STEPTERM as an example): 
        DATACOME:DB04206I – PXX END – EXTEND FAILURE DUE TO X37 ABEND
        DATACOME:DB01702I – DYNAMIC  EXTEND OF AREA ENF00700 HAS FAILED
        CAS9316E – STEPTERM “Insert  “ failed – rc(-258) r/s (X’F5F7E2F0F6)
        CAS9340I – TABLE  FULL – DBID=700 INTERNAL  NAME B22
        *CAS9208E –  CA-ENF DB:  DB Insert error SQLCODE=-258  SQLSTATE=57S06
        CAS9303E – Event STEPTERM no longer recorded due to DB error 0008
  • This article will discuss the reasons why a problem with the space can occur and describe methods to both resolve the immediate problem and avoid a future occurrence.

 
Question:

What can cause the ENF MUF to run out of space and what methods are available to resolve the problem?   
 

Environment:
  • Common Services for z/OS r14.1 ENF Component used for Event recording
  • Datacom/AD r14.0 or r15.0
  • Various CA products such as CA-7, Scheduler, CA-11 requiring Event Recording 
Answer:
Possible reasons why the database may encounter a space problem:
  • Initial space allocation was too small   
    • Recommendations is to initially allocate 500 cylinders for IXX700 and 1500 cylinders for ENF700 datasets. 
    • Monitor the usage for a representative work cycle and adjust if necessary
  • ENF parms are not set correctly
    • ARCHIVE and EVENT parms work together to keep the MUF self-sustaining entity
    • 5 key statements used to purge records
      • ARCHIVE(hhmm) or ARCHIVE(AUTO)
      • Runs once daily  
      • hhmm – execute based upon a time using the 24 hour clock (0100 or 1:00 am the default)
      •  AUTO – execute when the database reaches a specified percentage of capacity (80% the default)
      • hhmm the recommended method
      • 4 EVENT statements for every recorded record – STEPTERM used as example
      • EVENT(STEPTERM,ACT)             – Enables the event
      • EVENT(STEPTERM,REC)             – Record the event to the database
      • EVENT(STEPTERM,RP=nn)         – The number of days to retain the records
        • Span of RP=1 - RP=3 most commonly used   
      • EVENT(STEPTERM,PURGE=Y)    – Purge the records when RP value is met  
      • PURGE and/or RP statements sometimes omitted
  • ENF parms listed above prevent the database from reaching capacity
    • Delete records when no longer needed by individual CA product
    • Run on a scheduled basis
    • Eliminate user intervention
Should space problems be encountered despite the parms it is possible to dynamically purge events by using an ENF PURGE(event)  console command.   Follow these steps:
  • Determine the event with the greatest number of records     
    • Execute a Datacom CXX report against the ENF Database, DBID=700
      • Using the STEPTERM event as an example
    • Issue the ENF PURGE(event) command using one of two formats
      • ENF PURGE(STEPTERM)
      • F ENF,PURGE(STEPTERM)
  • If the CAS9303E message was issued for the named event (STEPTERM)
    • Neecessary to re enable recording
      • Accomplished with ENF EVENT(event,REC) command
        • ENF EVENT(STEPTERM,REC)
        • F ENF,EVENT(STEPTERM,REC)   
Additional Information:
Refer to the Common Services for z/OS r14.1 Product Documentation for details on the specific ENF parms and commands