Resolving DBH6007E messages from Datacom Health Checker processing
Article ID: 42567
Updated On:
Products
Issue/Introduction
With my ENF IMUF, I received an error message:
DBH6007E One or more Datacom/DB transactions have been force check pointed.
This was related to the Health Checker item DTCM_DB_FORCE_CHKPT@ENFMUF2
What do I need to do to address this?
Cause
Based on the name shown in the message, this message was produced on a MUF that supports the Common Services/ENF application. However, it can apply to any MUF, and this article will address all situations.
Several factors could lead to this Health Checker message, but the most common cause is that the Log Area (LXX) for this MUF is not large enough to handle the volume of updates being processed. If the MUF uses the LOGRCV NEVER MUF Startup Option, this MUF may not spill recovery records to an RXX to use for database recovery, but the LXX is still used for transaction backout processing, in the event that a currently-running, non-committed activity fails.
The explanation for this Health Check text says:
DBH6007E - One or more Datacom/DB transactions have been force check pointed. Explanation: One or more tasks for which transaction backout was specified, did not issue checkpoints (commits) frequently enough relative to the LXX's size. The LXX is DB's log.
Resolution
If using MUF Startup Option LOGRCV NO, the RXXROLLBACK settings need to be reviewed to be sure that rollback processing is adequately managed for your MUF.
If using LOGRCV NEVER, the LOGRCV and RXXROLLBACK changes do not apply to this MUF.
Within the explanation of the message is the change needed:
In addition, the LXX could be enlarged. If this route is chosen you must bring MUF down and run a DBUTLTY INIT of the LXX with a larger dataset.
Here are the steps to enlarge the LXX:
- If you are using inactive logging (MUF Startup Option LOGRCV NO), run a job to spill the log data to the recovery file (RXX). If not using logging (LOGRCV NEVER), this step can be skipped.
- Shut down your any application that is using the MUF, and then shut down the MUF itself. (For ENF tasks running with IMUF, just shut down ENF.) Be sure that the MUF ends cleanly and without errors.
- Using ISPF option 3.2 or 3.4, rename the current LXX file to something else - like ...LXX.OLD;
- Using ISPF 3.2, allocate a new LXX file with the same name that the previous file had. Allocate the file with double or triple the allocation of the previous LXX file to minimize the likelihood of running into this problem again.
- Once the file is allocated, initialize the new LXX file using this JCL:
//JCL JCLLIB ORDER=(<<YOUR DATACOM>>.CUSPROC)
//*
//INITLXX EXEC PGM=DBUTLTY,REGION=6M,PARM='/PGMMONTH=1'
// INCLUDE MEMBER=B15STLIB <<-- CHANGE 15 TO 14 FOR VERSION 14
// INCLUDE MEMBER=B15DDCXX <<--/ /
// INCLUDE MEMBER=B15DDOUT <<---/
//SYSIN DD *
INIT AREA=LXX,BLKSIZE=32760,TSN=########,VARIABLE=YES
*
* NOTE: SET THE TSN VALUE TO 10,000 HIGHER THAN THE DECIMAL CONVERSION
* OF THE VALUE SHOWN IN THE MUF "RESTART" OUTPUT FOR:
* LOG FILE HIGHEST TRANSACTION SEQUENCE NUMBER
*
/*
In the MUF output, the DD file called RESTART contains the Sequence Number referenced above. The report looks like this excerpt:
LOG FILE (LXX) OUTPUT
LOG FILE OPEN - NO
LOG FILE SPILLING - NO
LOG FILE SPILL PENDING - YES
MASTER LIST RCV OPTION - NO
LOG FILE HIGHEST TRANSACTION SEQUENCE NUMBER - 00000A1A Here, A1A converts to 2586. Therefore, use 12586 in the INIT job above.
OPEN USER FILES - NO
When the above job has completed successfully, you can restart your MUF and then the applications that use the MUF.
Feedback
