Force checkpoint (DBH6007E) generated while using LOGRCV=NEVER
search cancel

Force checkpoint (DBH6007E) generated while using LOGRCV=NEVER


Article ID: 272152


Updated On:


Datacom Datacom/AD Datacom/DB


During a z/OS Health Check, the z/OS team received this Health Check exception:

SYSPLEX:    sysplex   SYSTEM: lpar                                    
START TIME: 08/19/2022 10:14:40.539113                                  

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?



Release : all

Component : Datacom/AD

Component : Datacom/DB


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.