Restarting an ADBTEP2 job
When ADBTEP2 runs, it checks to see if a record exists
within the checkpoint table that matches the worklist
parameter
for the user ID that submitted the job.
If a record does not exist, ADBTEP2 creates it and starts with
the first statement in the batch statement list. If a record exists,
ADBTEP2 proceeds based on the RESTART
parameter.
When RESTART(NO)
is specified, ADBTEP2 starts with
the first statement in the batch statement list. When either no RESTART
parameter
is provided or RESTART(YES)
is specified, ADBTEP2
repositions itself within the batch statement list and resumes processing.
ADBTEP2 has a simple restart capability. When the failing statement is SQL, a restart occurs at the last commit point prior to the failing SQL statement, which can be either an SQL COMMIT statement or an implicit commit that is performed while successfully completing a non-SQL function, such as a Db2 command.
If the failing statement is not an SQL statement, ADBTEP2 repositions
to this statement. It is possible, although not likely, for the job
to fail after executing non-SQL statements and before ADBTEP2 can
update and commit the checkpoint record. In this case, ADBTEP2 positions
on this non-SQL statement. Non-SQL statements cannot be rolled back
if a failure occurs during ADBTEP2 checkpoint/commit. If you determine
that the non-SQL statement completed, you can instruct ADBTEP2 to
skip this statement on restart by using the N (skip-next) line command.
ADBTEP2 reports the successful implicit commits that it performs before
and after non-SQL statements. You can also determine whether ADBTEP2
failed on non-SQL statements by viewing the checkpoint record: the Restart
Command
field is blank if an SQL COMMIT was the last commit
or if the last commit was an implicit commit as a result of completing
a non-SQL statement. If the last commit was an implicit commit ahead
of non-SQL statements, the Restart Command
field
is set to the type of non-SQL statement (for example, -STA
).
If ADBTEP2 determines that a utility was running at the time of failure, ADBTEP2 obtains information from Db2 (if the utility is known to Db2) and restarts accordingly.
The following figure illustrates the checkpoint for the job with
worklist DOC1
. Because the Restart Command
field
is blank, we can determine that the last instruction performed was
either an SQL COMMIT or a non-SQL statement that completed with an
implicit commit. If we issue an N (skip-next) line command, Figure 2 is displayed.
The checkpoint number has been increased by one.
In Figure 3, DOC2
has
a Restart Command
value that indicates that a COPY
statement failed. The value in the Restart Action
field
determines the action to occur when ADBTEP2 repositions. For utilities,
the value can be:
- C
- Restart current (ADBTEP2 default)
- P
- Restart phase
- R
- Restart from the beginning of the utility
- S
- Skip running the utility
The value in the Restart Action
field can also
be 'H', which indicates that the ADBHOLD table contains failed DSN
commands. These failed DSN commands can be reprocessed when the job
is restarted with RESTART(YES).
The U line command (Update) on this panel can be used to change
the restart option for utilities. For example, you can change the C
to
an R
. For non-SQL statements, only the options S
(skip) and R (rerun or reissue) are valid.
Figure 4 shows
the result of using the N (skip-next) line command against DOC2
.
The restart command is now S
and the commit number
has not been increased. The Restart Command
still
displays the original type of the failing command, in this case COPY
,
as opposed to Figure 2,
which shows the command as UNKNOWN
.