Initialization

JES2 can enter the checkpoint reconfiguration dialog during initialization processing for the following reasons:

JES2 could not determine, or required verification of, the checkpoint data set specifications
You specified PARM=RECONFIG as a JES2 start option
You specified RECONFIG=YES on the CKPTDEF initialization statement.

JES2 automatically enters a dialog either because of an error condition (as noted in the first instance) or because you have requested it to do so (as noted in the second and third instances).

A checkpoint reconfiguration entered at initialization is limited to the initializing member only; it is not a multi-system reconfiguration as are all other reconfiguration types. As such, the reasons for entrance can be unique. For example, consider the following scenario:

An I/O error occurred and CKPTn was forwarded at that time
The I/O error prevented JES2 from writing the forwarding information into the data set in error or possibly from reading it during this JES2 initialization. See Using the NEWCKPTn data sets for a discussion of JES2 checkpoint data set forwarding.
You did not update the initialization data set to reflect the new checkpoint data set definition(s)
When initializing, JES2 will prompt the operator for the CKPTn definition(s) currently being used by the other MAS members.

Note: After completing all interactions with the operator, JES2 will verify the last written time stamp of the data set it will read the checkpoint from. The checkpoint is read from either the CKPTn specified on the PARM= on JES2 start or as determined by JES2 processing. This verification is an attempt to verify that JES2 is reading from the correct checkpoint data set. Ultimately it is the installations' responsibility to ensure that the correct data sets are used to start JES2. However, some common problems are detected by JES2. Normally, the $HASP478 message is not highlighted and is issued for informational purposes only. However, if JES2 detects a potential problem with the last written times of the checkpoint data set(s), then the message is highlighted and followed by the $HASP441 WTOR. When this happens, the installation should verify that the time stamps associated with the data set being matched with the time the MAS was last active and would have last written the checkpoint. If not, then reply 'N' to the $HASP441 message to terminate in response to $HASP478.