As part of planning your installation's operations so that operators
or the system can respond promptly and appropriately to disabled wait
states, consider activating the AutoIPL function. AutoIPL can re-IPL z/OS®, or take a stand alone dump
(SADMP), or take a SADMP and have SADMP re-IPL z/OS when it has finished. The desired actions
are represented in an AutoIPL policy, which you state in a DIAGxx
parmlib member that the system checks at wait state time.
AutoIPL requires hardware support, standard on all
systems beginning with System z10™ Enterprise
Class (z10 EC). For System z9® Enterprise Class (z9 EC), AutoIPL is provided with feature code
9904 and hardware driver 67 or later (both are required). After applying
the feature, you must IPL the system to detect AutoIPL on the z9 EC.
AutoIPL is also available for a z/OS guest on z/VM® Release
5.3.0 or later.
AutoIPL works on a single-system basis (that is, a disabled wait
state on a given system prompts that system to take the actions stated
in the AutoIPL policy of the system).
Use
the following steps to activate AutoIPL:
- If the policy is to include the taking of a SADMP, generate SADMP
on some volume, ensuring that the level of SADMP is correct for the
level of z/OS, that the SADMP
data set is of sufficient size and has the correct properties set.
- Code an AUTOIPL statement in a DIAGxx parmlib member, using the
syntax described in the z/OS MVS Initialization and Tuning Reference.
- Prompt the system to read the DIAGxx member, either by setting
up the parmlib concatenation and IPLing, or by issuing a SET DIAG=xx
operator command.
- Issue the DISPLAY DIAG command to verify that the policy established
is what you intended.
To deactivate AutoIPL:
- Code the following statement in the DIAGxx member, and prompt
the system to read it:
AUTOIPL SADMP(NONE) MVS(NONE)
- Next, issue DISPLAY DIAG to verify that the system
displays AUTOIPL SADMP(NONE) MVS(NONE).
Part
of the AutoIPL support includes a hard-coded table of wait state and
reason codes, called the wait state action table (WSAT), which is
part of the z/OS nucleus. Each
entry has a flag to indicate whether the SADMP part of the AutoIPL
policy should be honored, and a flag to indicate whether the MVS™ part of the AutoIPL policy should
be honored. (This is necessary because a few z/OS wait states are inappropriate for a SADMP
or a re-IPL.)
When the Loadwait component of z/OS is
invoked to load a disabled wait state, it checks the requested wait
state and reason code against the table.
For non-restartable wait states, Loadwait will fully
honor the AutoIPL policy unless a matching WSAT entry is found that
has one or both flags off. If a bit is found off, then the corresponding
SAD or re-IPL will not be performed.
For restartable wait states, Loadwait will ignore
the AutoIPL policy unless a matching WSAT entry is found that has
one or both flags on. If a bit is found on, then the corresponding
SAD or re-IPL will be performed. As of this writing, the WSAT contains
no entries matching any restartable wait state and reason codes, so
a restartable wait state request will not result in any AutoIPL action.
The contents of the wait state action table are described in Wait state action table (WSAT).
Note: - AutoIPL is not appropriate in a GDPS® environment.
- Do not specify a load device that is defined as a secondary device
in a PPRC pair.
- If an AutoIPL action is performed, the following message does
not appear at the HMC: Central processor (CP) x is in a nonrestartable
stopped state due to a System Control Program (SCP)initiated reset
of the I/O interface for partition n.
- Verify the required hardware support on the system by attempting
to establish an AutoIPL policy (with SADMP setting other than NONE).
If message IGV010I appears, some or all the required support is not
present.
- AutoIPL supports only ECKD™ devices.
- To give sysplex failure management (SFM) some time
to perform fencing isolation on the failed system, AutoIPL might delay
for several minutes before actually initiating the SADMP or the re-IPL.
During this time, the failed system will appear to be hung.
- The AutoIPL functions can optionally be requested
on a VARY XCF command issued to remove a system from
a sysplex. They may not be performed as requested if the sysplex partitioning
and/or sysplex resource cleanup activities initiated on the removed
system cause that system to request a disabled wait state other than
the one associated with the SADMP and/or REIPL keywords specified
on the VARY XCF command. If a wait state is requested as a result
of sysplex partitioning and/or resource cleanup activities on the
removed system, the AutoIPL functions are performed based on the
wait state code that was actually requested to be loaded, rather than
based on the AutoIPL functions that were requested on the VARY XCF
command.
- Specialty processors such as the System z® Integrated Information Processor
(zIIP) and System z Application
Assist Processor (zAAP) do not support the Load function that AutoIPL
initiates. If a wait state that should result in AutoIPL actions is
requested on a specialty processor, the system attempts to switch
to a general-purpose processor. If a switch cannot be performed, the
AutoIPL action is not performed, and the system loads the requested
wait state.