How the Job Is Reinterpreted

After disposition processing is completed, the job is reenqueued by the job entry subsystem and is eligible for selection. After the job is selected, the system begins restart processing by reinterpreting the job. The system uses an internal representation of the original job to perform this function. The job is not read in again.

When the information is merged and step restart occurs, the following changes occur:

Except for data sets not opened during the original execution that requested nonspecific tape volumes, data sets specified as NEW in the restart step have their dispositions changed to OLD.
In the case of data sets for which nonspecific volumes are requested in the restart step, the device type and serial numbers of the volumes assigned to the data sets during the original execution are used.
In the case of multivolume data sets, the volume in use at the checkpoint, and not the first volumes of the data sets, are mounted (if they have not remained mounted) during the restart. For VSAM, however, volume mounting is based on the present catalog information and may result in the mounting of unneeded volumes; for example, the first volume of a sequential data set may be temporarily mounted although it is no longer required at the checkpoint being restarted and may be demounted almost immediately. This situation may be avoided through specification of the parallel mount subparameter of the DD statement UNIT parameter (UNIT=(,P)). For further information, see the z/OS MVS JCL User's Guide.
The system-generated name for any temporary data set uses the time stamp obtained when the job was originally interpreted.

In addition, any modification made to the job's environment by the use of the dynamic allocation facilities prior to the last checkpoint appears as it did at the time of the checkpoint.