Issues with DLI Batch Backout and Checkpoints

Current Situation

The situation is: IMS 12.1, batch jobs running in DLI mode, dynamic backout is not enabled, no IRLM, no RSR tracking, DBRC is Force, databases are registered to DBRC, application program takes checkpoints.

Our normal procedure is for DLI applications to take one checkpoint at the beginning of the step, and then regular checkpoints thereafter. But since performing checkpoint restarts is not a consequence-free process, we do not perform a checkpoint restart for jobs unless they have run for a long time. (“Long” is defined as “long enough that performing the checkpoint restart is worth the trouble.”) Instead we restart the step at the beginning.

This means that if the step performed database updates, we must perform Batch Backout (using DFSBBO00) to the beginning of the step. For steps that are taking checkpoints, this means we BBO to the first checkpoint.


When a DLI step abnormally ends, IMS provides a helpful message to indicate if you need to do Batch Backout:

DFS036A BATCH BACKOUT NOT REQUIRED FOR jobname imsid
or
DFS036A BATCH BACKOUT IS REQUIRED FOR jobname imsid

Except that it doesn't.

If the message says “BATCH BACKOUT IS REQUIRED”, then this does mean what it says.

But if the message says “BATCH BACKOUT NOT REQUIRED” it actually means one of two things:

A. The step has not updated any databases.
B. The step has updated databases, but there were no updates since the last checkpoint.

This is because DBRC and IMS are making an assumption: they assume that if a DLI step abends, and dynamic backout is not enabled, the programmer is going to backout to the last checkpoint (if required) and then perform a true checkpoint restart.

So the first problem is, if you see the “BATCH BACKOUT NOT REQUIRED” message, how do you know which situation are you in? Are you in situation A, which means that no BBO is required under any circumstance? Or are you in situation B, which means that you really do need to do BBO if you intend to restart anywhere other than the last checkpoint?

One way to tell is to search the IEFRDER log files for the particular log record types that indicate database updates. This does work, except that a) it isn't so easy when the IERFDER is on tape, b) it is inefficient for larger logs, and c) it doesn't actually tell you if you need to do BBO for a particular checkpoint.


Forcing Backout

It used to be that you could run BBO anyway. If you were in case A it just wouldn't backout anything; it would give an error return code that indicated that there was nothing found to backout. If you were in case B it would go ahead and backout to the requested checkpoint.

This hasn't been the case for some time. Now if you run BBO when “BATCH BACKOUT NOT REQUIRED”, it abends with U0041 and error message:

DFS041I DBRC SIGNON REQUEST, RC=28 IMTJ

What this message really means is that DBRC doesn't have a “subsystem entry for the log supplied to batch backout”. So, it means one of two things:

1. You have supplied BBO with the wrong log file. Trying to proceed with this file would be VERY BAD.
2. You have supplied BBO with the right log file, but DBRC doesn't want to proceed.

Now your problem is, how do you tell which of these situations are you in? Can you go ahead and backout to the previous checkpoint? Or would that cause catastrophic destruction of the database? That answer is: there is no way to know, aside from dumping DBRC and inspecting the PRILOG records.

The manual says that if you are in situation B (no updates since the last checkpoint) and you want to backout to a previous checkpoint, you should run BBO using DBRC=C and with the BYPASS LOGVER control card.

This does work, but realize that we are telling DBRC to skip all log verification. It won't even verify that the provided log file is in DBRC in a PRILOG (I think), nor that there hasn't been a reorg after it was created, or that it is even for the right system, and so on. We might as well not have DBRC at all.