|
- CKPTOPT=CKPT1|CKPT2|HIGHEST
- Specifies which checkpoint data set JES2 reads as the source
for building the JES2 work queues during a restart. CKPT1 and CKPT2
refer to the CKPT1= and CKPT2= parameters on the CKPTDEF initialization
statement, respectively. HIGHEST indicates that you will allow JES2
to read the checkpoint data based on the level tokens associated with
the checkpoint data sets. (See the CKPTDEF statement in this chapter and z/OS JES2 Initialization and Tuning Guide for further
discussion on selecting an appropriate checkpoint data set.)
Note: The method used by JES2 to determine the highest data set
to read from, is not foolproof. If you are in a recovery scenario
and know that one of the checkpoint data sets does NOT have the current
checkpoint information, then you should specify the CKPTn option that
reads from the data set that does contain current checkpoint information.
Modification: Hot start.
- COLD_START_MODE = z2 | z11 |
Null
- Specifies the checkpoint mode ($ACTIVATE LEVEL) for JES2 to
use for COLD starts. By default, JES2 does COLD starts in z11 mode.
To set JES2 COLD starts to z2 mode, specify COLD_START_MODE=Z2.
Set
this parameter in your initialization deck to ensure that any unplanned
COLD starts are done in the intended mode.
If this parameter
is specified, initialization issues the following warning messages
if JES2 is warm started with a COLD_START_MODE that does not match
the mode of the read checkpoint:
$HASP442 INITIALIZATION STATEMENTS CONFLICTING WITH SAVED VALUES FOLLOW:
$HASP496 OPTSDEF COLD_START_MODE=Z11 SAVED VALUE OF Z2 WILL BE USED
If COLD_START_MODE is not specified, no warning message is issued.
Note: The JES2 start parameter UNACT overrides the COLD_START_MODE
parameter and causes JES2 to start in z2 mode.
Modification: Hot start.
- CONSOLE=Yes|No
- Displays (or changes) the value of the CONSOLE start option.
If set to YES, the operator will be prompted for additional initialization
statements after the initialization deck is processed. See
the z/OS JES2 Initialization and Tuning Guide for further information on the interaction
of this initialization statement and the CONSOLE initialization control
statement.
Modification: Hot start.
- LIST=Yes|No
- Specifies whether or not to copy subsequent initialization statements
to the HASPLIST DD statement.
Modification:
Hot start.
- LISTOPT=Yes|No
- Displays (or changes) the value of the LISTOPT start option.
If YES, the initialization statements are printed if a device is specified.
Modification: Hot start.
- LOG=Yes|No
- Specifies whether or not to copy subsequent initialization statements
to the printer specified by the HARDCPY console.
Modification: Hot start.
- LOGOPT=Yes|No
- Displays (or changes) the value of the LOGOPT start option.
If Yes, the initialization statements are logged if a device is specified.
Modification: Hot start.
- RECONFIG=Yes|No
- Displays (or changes) the value of the RECONFIG start option.
If Yes, the operator can specify RECONFIG to cause JES2 to use the
checkpoint data set definitions as defined in the initialization data
set, thereby overriding any/all previous checkpoint data set forwarding.
(See z/OS JES2 Initialization and Tuning Guide for
a full discussion of checkpoint data set forwarding and reconfiguration.)
Modification: Hot start.
Note: This
parameter must never be specified in the PARMLIB
member.
- REQMSG=Yes|No
- Displays (or changes) the value of the REQ|NOREQ start option.
If Yes, the $HASP400 ENTER REQUESTS message is displayed, prompting
the operator for the $S command.
Modification:
Hot start.
- SPOOL=VALIDATE|NOVALIDATE
- Specifies whether or not JES2 validates the track group map.
VALIDATE will recover potentially lost track groups. NOVALIDATE
is faster but will not recover any track groups that are potentially
lost.
Note: On an all-member warm start, you can use this
parameter or the SPOOL=VALIDATE start option to request that JES2
validate the track group map. This is typically not needed unless
you receive indications from JES2 such as the following:
Immediate spool validation can then be useful
as an immediate validation of the track group map in conjunction with
ongoing track group validation cycle wherein all track groups are
validated once every 7 days.
Modification:
All-member warm start.
|