Recovery Process Boost
In addition to Startup boost and Shutdown boost, Recovery Process (RP) boost is a boost class that can help accelerate system recovery. Recovery Process boost provides short-term acceleration for specific recovery events in z/OS. The applicable recovery events for Recovery Process boosts are limited to:
- 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 CF data-sharing member. 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.
Recovery Process boost applies only to the z15. LPAR firmware in z15 T01 and T02 provides the support for the short-duration Recovery Process boosts. Recovery Process boost periods are restricted to 5 minute durations and are limited to 30 total minutes per partition per 24 hour period.
Recovery Process boosts are managed internally by z/OS, with the operating system initiating the boosts as these recovery events take place, and only on the images that are actually participating in or affected by these events. Recovery Process boost periods are started and ended solely by z/OS operating system controlled events. When initiating the RP boost, z/OS initiates whichever boost types (speed boost, zIIP boost, or both) are identified by the BOOST= system parameter currently in effect for the image. During Recovery Process boost periods, any available program within the boosting partition may be executed on a zIIP engine as defined and controlled by IBM's technological measures, when zIIP boost is active.
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 will extend 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 towards the system (as it does during startup boost). Instead, WLM essentially ignores short-duration recovery boosts for workload routing purposes, because they are too short-term.
Additionally, there is “boost class” for Recovery Process boost that appears in various system messages, ENF signals, SMF fields, and other z/OS APIs. For more information please refer to:
