search cancel

CA-ENF DB: Database Insert error:72 reason:0

book

Article ID: 113442

calendar_today

Updated On:

Products

CIS COMMON SERVICES FOR Z/OS 90S SERVICES DATABASE MANAGEMENT SOLUTIONS FOR DB2 FOR Z/OS COMMON PRODUCT SERVICES COMPONENT Common Services Datacom/AD CA ECOMETER SERVER COMPONENT FOC EASYTRIEVE REPORT GENERATOR FOR COMMON SERVICES INFOCAI MAINTENANCE IPC UNICENTER JCLCHECK COMMON COMPONENT Mainframe VM Product Manager CHORUS SOFTWARE MANAGER CA ON DEMAND PORTAL CA Service Desk Manager - Unified Self Service PAM CLIENT FOR LINUX ON MAINFRAME MAINFRAME CONNECTOR FOR LINUX ON MAINFRAME GRAPHICAL MANAGEMENT INTERFACE WEB ADMINISTRATOR FOR TOP SECRET Xpertware Compress Data Compression for MVS Compress Data Compression for Fujitsu

Issue/Introduction

After switching to backup CPU, I received the following errors. Even recycling ENF STC does not help to resolve this problem.  

13.09.03 STC00408 *CAS9359E - Unrecoverable Database subtask failure detected. Recycle ENF 
13.09.03 STC00408 *CAS9208E - CA-ENF DB: Database Insert error:72 reason:0 
13.09.03 STC00408 CAS9303E - Event JOBFAIL no longer recorded due to DB error 0012 

Could you please tell me what is causing the issue? 

Why do I get the message: CA-ENF DB: Database Insert error:72 reason:0 
after switching to backup CPU? 
 

Environment

CA Common Services 14.1 - z/OS supported releases - 

Resolution

Looking at the ENF joblog, you can check if LOGRCV was set to NO in your Datacom environment, 
the default is LOGRCV=NEVER. So the recommendation is to go into your : 

DATACOM.CUSMAC(AXDATIN1) and set it back to LOGRCV=NEVER; please check if yours is set to LOGRCV=NO.
 
What NEVER does is to allow the LOGFILE (LXX) to be reused and will not write anything to a Recovery File (RXX). 

The LOGRCV=NO allows these records to be written periodically but only when necessary. The LXX/RXX files are used for backup and recovery. Keep in mind, however, that the ENF database is self sustaining, contains only transient data, and no backup is necessary. 

So here are our recommendations: 

1. Edit your DATACOM.CUSMAC(AXDATIN1) member and change the current value of LOGRCV from LOGRCV=NO to LOGRCV=NEVER. 

2. Shutdown ENF and run DATACOM.R14.INSTJCL(AD14LXXI) to reinitialize the log file to use the LOGRCV value.
 
3. Restart ENF. 

This will clear up the situation and prevent this from occurring in the future.