Using the automatic IPL function

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:

  1. 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.
  2. Code an AUTOIPL statement in a DIAGxx parmlib member, using the syntax described in the z/OS MVS Initialization and Tuning Reference.
  3. 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.
  4. Issue the DISPLAY DIAG command to verify that the policy established is what you intended.

To deactivate AutoIPL:

  1. Code the following statement in the DIAGxx member, and prompt the system to read it: 
    AUTOIPL SADMP(NONE) MVS(NONE)
  2. 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:
  1. AutoIPL is not appropriate in a GDPS® environment.
  2. Do not specify a load device that is defined as a secondary device in a PPRC pair.
  3. 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.
  4. 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.
  5. AutoIPL supports only ECKD™ devices.
  6. 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.
  7. 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.
  8. 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.