JES2 honors the checkpoint configuration definition across any JES2 restart and forwards data sets based on the CKPTn and NEWCKPTn definitions. However, for consistency between your initialization data set and the new checkpoint definitions, you should update your initialization data set as soon as possible.

During JES2 checkpoint reconfiguration processing, JES2 tries to add a pointer in each replaced checkpoint data set to provide a ‘forwarding trail’. (See Using the NEWCKPTn data sets for a discussion of JES2 checkpoint data set forwarding.) You cannot delete this series of old checkpoint data sets until you have updated your initialization data set to point to your current checkpoint. If JES2 was unable to write the forwarding information into the old checkpoint (possibly caused by an a I/O error) you should update the CKPTDEF statement in all your initialization data sets as soon as possible. This effectively makes your current checkpoint definition permanent and eliminates the forwarding trail. Otherwise, whenever you warm start JES2, JES2 will enter a reconfiguration dialog at initialization.

Attention: If, on a JES2 restart, you specify RECONFIG as an option in response to the $HASP426 SPECIFY OPTIONS message or you have previously added RECONFIG on an S JES2 command, JES2 will ignore all checkpoint data set forwarding previously defined. JES2 will override all forwarding and use the checkpoint data set you specified from the console. If this is inappropriate to your restart situation, be certain to have either redefined your checkpoint data sets in your initialization data set or do not use the RECONFIG option. See Specifying the Start Options for information on specifying JES2 start options and z/OS MVS JCL Reference for specifying the JES2 PROC statement.