Restarting an online utility
If a utility finishes abnormally, you might be able to restart it. You need only resubmit the job and DB2® attempts to restart it. However, you might need or choose to make other changes before you resubmit the job.
About this task
Utilities can be restarted with one of the following two methods:
- Phase restart
- The utility restarts from the beginning of the phase that was being processed. This method is indicated by the parameter RESTART(PHASE).
- Current restart
- The utility restarts from the last checkpoint that was taken during the execution of the utility phase. If the utility phase does not take any checkpoints or has not reached the first checkpoint, current restart is equivalent to phase restart. This method is indicated by the parameter RESTART or RESTART(CURRENT).
Restarting a utility job is not always possible. If you cannot restart a utility job, you might have to terminate it to make the data available to other applications. To terminate a utility job, issue the DB2 TERM UTILITY command. Use this command only if you must start the utility from the beginning.
Procedure
To restart an online utility:
- If needed, make changes to the utility job. Use the following
guidelines:
- Do not specify z/OS® automatic step restart.
- Ensure that the required data sets are properly defined. Recommendation: Allocate the data sets by using TEMPLATE statements that do not specify the DISP and SPACE parameter values. When these parameters are not specified, DB2 determines the correct disposition and size of these data sets.
- Check the DISP parameters on the DD statements. For example, for
DD statements that have DISP=NEW and need to be reused, change DISP
to OLD or MOD. If generation data groups (GDGs) are used and any (+1)
generations were cataloged, ensure that the JCL is changed to GDG
(+0) for such data sets.
Automatically generated JCL normally has DISP=MOD. DISP=MOD allows a data set to be allocated during the first execution and then reused during a restart.
When restarting a job that involves templates, DB2 automatically changes the disposition from NEW to MOD. Therefore, you do not need to change template specifications for restart.
For any data sets that are not dynamically
allocated, ensure that the DD name that is specified in the restart
JCL matches the DD name for the original job. Do not change DD names
on a restart job. If the LOAD utility is restarted with a different SYSREC data set from the SYSREC data set for the initial invocation, the data control block (DCB) parameters must be the same as the SYSREC DCB parameters for the initial invocation. RESTART(PHASE) is recommended. RESTART(CURRENT) might have unpredictable results because data set checkpoint information is not used during restart processing.
- For any data sets that are dynamically allocated,
ensure that the file sequence numbers in the restart job match those
file sequence numbers in the original job.
- For data sets that are not cataloged, ensure
that any explicit VOLSER specifications in the restart job match those
specifications in the original job. If you copy a work data set, such
as SYSUT1, after abend B37, and the number of volumes changes, do
not specify RESTART(CURRENT). If you do, abend 413-1C occurs. To prevent
this abend, start the utility in RESTART(PHASE).
- For any cataloged data sets, do not specify VOLSER. Let DB2 determine the VOLSER value of the data sets from the system catalog.
- Include all of the original utility statements and do not change the position of any other utility statements that have executed. During restart processing, DB2 remembers the relative position of the stopped utility statement in the input stream. The exception is DIAGNOSE statements. You can add or delete DIAGNOSE statements as needed.
- Do not change the utility function that is stopped and the DB2 objects on which it is operating. However, you can change other parameters that are related to the stopped step and to subsequent utility steps.
- Do not change any EXEC SQL or OPTIONS utility control statements that executed before the stopped utility, if possible. If you must change these utility control statements, use caution; any changes can cause the restart processing to fail. For example, if you specify a valid OPTIONS statement in the initial invocation, and then on restart, specify OPTIONS PREVIEW, the restart fails.
- Use caution if you change LISTDEF lists before you restart the utility. When DB2 restarts list processing, it uses a saved copy of the list. Modifying the LISTDEF list that is referenced by the stopped utility has no effect. Only control statements that follow the stopped utility are affected. See How utilities restart with lists.
- Use caution if you change TEMPLATE statements before restarting the utility. See How utilities restart with templates.
- If you are using the DSNUTILS stored procedure, specify NONE or ANY for the utility-name parameter. These values suppress the dynamic allocation that is normally performed by DSNUTILS. You can then specify TEMPLATE statements (in the utstmt parameter) to allocate the necessary data sets.