Recovery process boost

In addition to shutdown boost and IPL boost, the recovery process boost class can help accelerate system recovery and diagnostic capture events. Recovery process boost provides short-term acceleration for specific recovery events in z/OS.

Recovery process boost is available beginning with z15 (LPAR MCL P46602.005 for z15 Driver 41C, bundle S29 or higher). Additional use cases are available with the z16. Recovery process boost periods are restricted to durations of 5 minutes or less and are limited to 30 total minutes per partition in a 24-hour period.

The recovery events for recovery process boosts include the following.

• HyperSwap®

  Boost all systems participating in a Hyperswap process. HyperSwap processing is a coordinated, sysplex-wide recovery process that restores access to DASD devices following the failure of a storage controller. Its recovery time is sometimes limited by slow processing on one or more participating systems.

• Coupling Facility data-sharing member recovery

  Boost all systems participating in recovery from termination of a coupling facility (CF) data-sharing member that terminates with lock resources held. When a data-sharing member fails, the other surviving members have to do a lot of recovery/cleanup processing to free up locks and other data-sharing resources held by the failed member.

• Coupling Facility structure recovery

  Boost all systems participating in CF structure recovery processing, such as CF structure rebuild, duplexing failover, and re-duplexing. Recovering failed CF structures and their data can be a process that requires the participation of all systems that were using those CF structures, and can apply to many structures in cases like loss of a CF image.

• Sysplex partitioning

  Boost all surviving systems in the sysplex as they take on the additional workload of sysplex-partitioning-related recovery, after planned or unplanned removal of a system from the sysplex. When a system in the sysplex is removed, the surviving systems have to do more recovery processing to clean up after the failed system and free up resources that were held on the failed system.

With the z16 or higher, boosts for these additional recovery events are available.

• SVC dump

  Boost the system on which an SVC dump is being taken, to accelerate diagnostic capture and reduce the impact of dumping on the system while the dump is being taken. During the dump capture process, the entire system, and particular address spaces that are being dumped, are non-dispatchable for limited time periods as their memory is captured. The requirement for additional system memory resources during the dump capture and write processes can cause paging, page-stealing, and memory-shortage issues for other areas of the system.

  SVC dumps are not boosted by default. Use the CHNGDUMP command to set a minimum size threshold for boosting an SVC dump. For more information, see Managing recovery process boost.

• Middleware region startup
  Boost the system on which a middleware instance is being started or restarted, to expedite its startup and resource recovery processing. The boost applies to:

  • Any start or restart of an address space, including manual starts and starts initiated by automation or automatic restart manager (ARM)
  • Restart-in-place on the same system, or cross-system restarts on a different system. In the case of a cross-system restart of a middleware region, it is the boost configuration (that is, the WLM service definition classification rules) of the system where the restart is taking place that controls whether or not the restarted middleware gets a boost.
  • Planned recycle or failure restarts.

  An initial start of a middleware region is not boosted by recovery process boost if there is an IPL boost already active.

  In the case of a multi-step startup PROC, only the first step is boosted.

  Middleware region startup is not boosted by default. Use classification rules in your WLM service definition to control that. For more information, see Managing recovery process boost.

• HyperSwap configuration load

  Boost to accelerate the process of loading or reloading HyperSwap configuration and policy information, and to reduce the system impact while the load is in progress. This is active by default.

• Dynamic I/O activate

  Boost to accelerate dynamic I/O activate processing. This boost requires that certain conditions and criteria must be met before the boost is started.

Recovery events can overlap when a second recovery process boost occurs before a first one has used its entire boost period. If this happens, then the overlapping boosts are merged and z/OS extends the boost period to allow the full boost period duration for the overlapping recovery process. During a recovery process boost period, WLM neither routes work away from the system (as it does during shutdown boost) nor routes work towards the system (as it does during IPL boost). Instead, WLM essentially ignores short-duration recovery boosts for workload routing purposes, because they are too short-term.