Dispatch runs with an IDMS database.
Each time any database update is done, IDMS takes an image of the database area being changed. This is the before image.
After the modification is complete and saved, IDMS takes another image of the completed change. This is the after image.
If there is a problem like an abend or cancel, IDMS uses the journals to match the before images with after images.
If there is a 'before image' on the journal and there is no corresponding 'after image' then IDMS will 'rollback' the changes so that the database looks the way it did before the change/changes started by reverting back to the before image. This ensures that no partial updates are left and that there are no broken chains on the database. Here is an example of what the Dispatch log would show when IDMS is doing a warmstart and is recovering, using the journal files, after being cancelled:
10.01.49 JOB47091 IDMS DC202001L STARTING WARMSTART
10.01.52 JOB47091 IDMS DC202019L WILL ROLL OUT RUN UNIT ID 15493166
10.01.52 JOB47091 IDMS DC203005L PROGRAM-ID RHDCRUAL RUN-UNIT ID 15493166
10.01.52 JOB47091 IDMS DC202007L RUN-UNIT ID 15493166 ABRT CHECKPOINT WRITT
10.01.53 JOB47091 IDMS DC202009L SUCCESSFUL WARMSTART
In the example above there is only one run unit that needed to be rolled out. Perhaps it was a update from the Status task?
Depending on what is going on in the system at the time of the cancellation or an abend there could be many run units that need to be rolled out.
Some particular database changes, for instance adding a report recipient, can result in several before and after journal images since there are pointers in the database records to both the previous record and the next record in the set. A base report will have a pointer to the first recipient of the report, which in turn will have a pointer to the next recipient, as well as pointers to various other recipient related database records. This is what we are referring to when we talk about database chains.