Replacing a checkpoint data set

Replacing a checkpoint data set is a relatively simple procedure. Whether you have previously defined the corresponding replacement data set will determine how this can be done during the reconfiguration dialog.

If you have previously specified the corresponding replacement data set, NEWCKPTn={(DSName=,VOLser=)|(STRNAME=)}, either on the:

CKPTDEF initialization statement (only during a cold start) or
$T CKPTDEF command.

and it has not already been used, you can copy the appropriate in-storage checkpoint (CKPT1 or CKPT2) to the corresponding NEWCKPTn data set. Respond to the $HASP271 CHECKPOINT RECONFIGURATION OPTIONS and $HASP272 ENTER RESPONSE message pair with the appropriate “FORWARD” option (that is, a reply of ‘1’ or ‘2’).

The time you and JES2 are involved in a checkpoint reconfiguration dialog is time that the checkpoint is unavailable to the JES2 members. It is important to minimize this length of time if possible and understand how to best consolidate $T commands. Use a single $T CKPTDEF,NEWCKPTn=(...),RECONFIG=YES outside a reconfiguration to speed reconfiguration processing. Specifying NEWCKPTn and RECONFIG=YES on the same command eliminates any ambiguity to JES2 whenever multiple NEWCKPTn specifications are entered on different JES2 members within the same checkpoint cycle.

If you have not previously defined the corresponding replacement data set, or it has already been used, you can define it by responding CKPTDEF NEWCKPTn={(DSN=dsname,VOL=volser)|(STRNAME=strname)} to the $HASP271 CHECKPOINT RECONFIGURATION OPTIONS and $HASP272 ENTER RESPONSE message pair. JES2 will then reissue messages $HASP271 and $HASP272 so that you can copy the in-storage checkpoint as described previously.