CA-ENF DB: Database Insert error:72 reason:0
Article ID: 113442
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?
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.
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.
Feedback
Yes
No
Powered by
