Force checkpoint (DBH6007E) generated while using LOGRCV=NEVER
Article ID: 272152
Updated On:
Products
Issue/Introduction
During a z/OS Health Check, the z/OS team received this Health Check exception:
CHECK(CA_DTCM,DTCM_DB_FORCE_CHKPT@PRODMUF)
SYSPLEX: sysplex SYSTEM: lpar
START TIME: 08/19/2022 10:14:40.539113
CHECK DATE: 20151231 CHECK SEVERITY: MEDIUM-DYNAMIC
The most recent force checkpointed Datacom transactions are:
Jobname Run Unit Optional ID TSN Check Point Time
-------- -------- ---------------- -------- -------------------
JOBNS29D 32003 001E8987 08/18/2022 07:01:33
JOBNS29D 31816 001E8112 08/17/2022 07:01:18
* Medium Severity Exception *
After reading article 42567 - Resolving DBH6007E messages from Datacom Health Checker processing, why would there be a force checkpoint (DBH6007E message) done by my job if I am using LOGRCV=NEVER?
Environment
Release : all
Component : Datacom/AD
Component : Datacom/DB
Resolution
As with any database file, transaction updates need to be logged for both recovery purposes and for dynamic transaction backout purposes. In the event that the job has a problem where the updates most recently made need to be reversed, the LXX holds these updates. Therefore, even if you use LOGRCV NEVER -- which means that you are not planning a later Forward or Backward Recovery, you will still need the ability to back out uncommitted updates to your Datacom tables. This is a similar process to VSAM dynamic transaction backout, which will undo CICS updates when a problem happens.
According to the documentation on LOGRCV NEVER, you should carefully evaluate the impact of specifying NEVER because, with a LOGRCV value of NEVER, recovery is not possible and transaction backout can be compromised,” which is what you just experienced with the forced checkpoint. When that happens, if the transaction fails and needs to backout, it may not complete because we forced a checkpoint and could have overlaid records that were needed. In that case, the database could be left in a "partially updated" state, which could result in erroneous processing.
We recommend that you enlarge the LXX 20% or more, if you continue to get health check messages, to be able to hold all of the updates for a single job at one time.
In general, the LXX needs to be able to hold all the transactions for a single LUW (logical unit of work), in case it needs to reverse all those updates. This is accomplished one of two ways: either issue a Commit transaction to commit all the updates to the database more frequently, which makes each LUW smaller, or make the LXX bigger so that it can hold all the transactions for a single LUW.
Additional Information
As always, please contact Broadcom support for Datacom if you have further questions.
Feedback
