How Restart Processing Works With Log Apply

Log Apply restart processing is integrated with the Batch Processor restart function. When you execute a data set with Log Apply parameters, the Batch Processor generates a Batch Processor data set ID (BPID) for the control statement file. The Batch Processor writes this BPID to a row in the BPLOG table and then tracks the execution of the data set using sync points. The Batch Processor uses the BPLOG row and the BPID for its own restart control.
caladb2
Log Apply restart processing is integrated with the Batch Processor restart function. When you execute a data set with Log Apply parameters, the Batch Processor generates a Batch Processor data set ID (BPID) for the control statement file. The Batch Processor writes this BPID to a row in the BPLOG table and then tracks the execution of the data set using sync points. The Batch Processor uses the BPLOG row and the BPID for its own restart control.
Log Apply also generates a BPID when you execute the data set. However, this BPID is for the load format file and it is written to a different BPLOG row. The Log Apply BPID is qualified by the timestamp record in the data set (that is, in the LADFILE or input file). This record lets
CA Log Analyzer™ for DB2 for z/OS
control the restart when the input file is reused for subsequent Log Apply jobs. Log Apply tracks the execution of the load format file using successful commits as sync points.
When Log Apply executes, it inserts a restart row into the BPLOG table with SYNCID = 0. After each commit, Log Apply updates the row with the record ID of the input record from the load format file. After the first complete Log Apply execution, the restart row contains a SYNCID that equals the number of records processed in the input file.
When you restart a Log Apply job with the same input file, the timestamp at the beginning of the file dictates how the restart occurs:
  • If the timestamp in the input file matches the one in the BPID, Log Apply honors the SYNCID and skips that number of records.
  • If the timestamp in the file is older than the one in the BPID, Log Apply does not continue processing. You can use the RESTART command to resume processing.
  • If the timestamp in the file is newer than the one in the BPID, Log Apply starts processing at the beginning of the input file.
  • If no BPID is found for the input file, Log Apply starts processing at the beginning of the input file.
You can force Log Apply to start at the beginning of the input file by specifying the OVERRIDE parameter in the Batch Processor statements. This parameter ignores any previously applied records.
The following values in the BPLOG table relate to Log Apply:
  • Type L (Load record)
    Indicates that this record is a load record.
    CA Log Analyzer™ for DB2 for z/OS
    generates this value.
  • Status XC
    Indicates that a commit point was reached where all records were consistent.
How the Commit Frequency and Discard Limit Affect the Restart Process
Be attentive to the commit frequency value in relation to the discard limit. The commit frequency is specified in the Load Utility Control Card Variables profile panel. The discard limit is specified on the DML Activity Report Options panel. The discard limit specifies the threshold for discarded rows. Log Apply terminates processing when the threshold is exceeded. Specifying 0 continues processing regardless of the number of discarded rows. If processing terminates when the discard limit is exceeded, a restart begins processing only at the most recent commit.
For example, if you set the commit frequency to 3 and the discard limit to 5, the resulting processing flow is as follows:
Input Record #
Result
Input record 1
Success
Input record 2
Discard
Input record 3
Discard
Input record 4
Success
Input record 5
Discard
Input record 6
Discard
Input record 7
Success
COMMIT
n/a
Input record 8
Discard
STOP
n/a
Upon RESTART, input records 2, 3, 5, and 6 are lost when the restart occurs at input record 8. A discard limit of 1 catches all discards, but a restart must occur after every discard. A discard limit of 0 loses all discards that occurred before the last COMMIT.