Today’s mainframes run mission-critical workloads in top industries, including large financial institutions, insurance companies, healthcare, utilities, government, military, and a multitude of other public and private enterprises.
The beauty of mainframes lays in its flexibility, stability and security. They provide the ability to divide the resources of a single machine into multiple LPARs that run its own copy of OS. These LPARs are, in effect, equivalent to separate mainframes themselves and can operate independently or together as a group called sysplex that cooperate to process the work. This sysplex can run large commercial mission-critical workloads continuously and more efficiently.
Each mainframe has maximum central processor complex (CPC) capacity. In general, a z Systems machine has more than one LPAR running and they collectively use the CPC capacity of the machine, with the usage based on the weights that are defined in the HMC.
Given all these terrific capabilities, a question may also arise: Is there a way to control mainframe LPARs?
There may be a variety of reasons to control the mainframe. For example, there may be a need to control cost with usage-based software pricing models or you may want to limit the capacity of a test LPAR. These latches—called “capping”—come in many forms that limits the CPU usage of an LPAR. Capping is managed either by Workload Manager (WLM) or PR/SM.
Below are seven different latches that can regulate your mainframe.
Initial Capping (Hard Cap)
The usage of CPC capacity of an LPAR is based on the weights that are defined in the Hardware Management Console (HMC) that correspondence to partition share of CPC capacity. However, if an LPAR needs more than its share and other LPARs aren’t using their share, then PR/SM allocates more capacity for the LPAR that needs more than its share.
Initial Capping (IC), also called hard capping setting, prevents PR/SM from giving an LPAR more than its share even when there’s capacity available in CPC. So an LPAR that has IC set can’t exceeds its share. IC limit is defined in the HMC as relative weight.
Scope is a single LPAR and the capping is managed by PR/SM.
LPAR Absolute Capping
LPAR absolute capping is PR/SM controlled capping limit that applies to a single LPAR. Its limit is defined in the HMC as fractional number of processor. This capping is enforced independent of four-hour rolling average (4HRA). This is capping is also suitable for LPARs not running on z/OS.
Scope is a single LPAR and the capping is mange by PR/SM.
Group Absolute Capping
Group absolute capping is similar to the LPAR absolute capping but applies to groups of LPARs. Its limit is defined in HMC as a fractional number of processors. This capping is also controlled by PR/SM. The combined CPU capacity usage of these groups of LPARs can never exceed the group absolute capping limit at any time.
The scope is a group of LPARs and the capping is managed by PR/SM.
Defined Capacity (Soft Capping)
The defined capacity (DC) value that an LPAR needs to be controlled to is set in HMC. WLM tracks the 4HRA and compares that against the DC value. 4HRA is the measure of the LPAR usage. If 4HRA exceeds DC value, the LPAR is capped. WLM triggers the capping but it’s enforced by PR/SM. When this capping occurs, the work that supposed to be run on this LPAR gets delayed. If the WLM policy is set right, then WLM will run the most critical work and delays the low important work. Capping will be in effect until the usage (i.e., 4HRA drops below the DC value). At this point the LPAR functions normally. Since DC value is compared to the 4HRA value, the current CPU usage of this LPAR can go over DC value as long as the 4HRA value doesn’t exceed the DC limit.
The scope is a single LPAR, meaning that the DC value limits the CPU capacity for a single LPAR.
There is a limitation: DC only applies if LPAR has shared CPs. An LPAR with dedicated CPs cannot be controlled by DC. Also, good to know: DC can’t be used with Initial capping control or vice versa (i.e., you could have either one of those but not both).
Group Capacity Limit
Similar to DC, group capacity limit (GCL) controls the CPU usage for a group of LPARs on a single CPC. In mainframes, z/OS LPARs can be grouped together, called capacity groups. These LPARs should reside in same CPC but not necessarily same sysplex. GCL controls all LPARs in the capacity group. GCL value is set in HMC. The total 4HRA of all LPARs in capacity group cannot exceed the GCL value. If it exceeds the capacity group limit, then capacity group is capped by PR/SM and each member of the group gets its share based on its weight. Similar to DC, as the group 4HRA drops below the GCL, capping is removed. While 4HRA of the group is below GCL, each LPAR in the group can use the capacity it needs.
Within capacity group, in addition to its group share, each LPAR in the group can have DC. In such cases, minimum of calculated group share and DC is used to cap.
The scope is a group of LPARs belonging to same CPC.
Resource Group Capping
Resource group (RG) provides the ability to control the maximum and the minimum CPU capacity given to the service classes (workloads) that are connected to this RG. If workloads exceed the maximum limit, then WLM caps the CPU usage of it.
WLM manages the workloads to the goals defined in the service definition. If a workload is missing its goal, then WLM try to help it by assigning more resources to it. In that process, WLM may take away resources from other workloads that are meeting their goals. RG minimum and maximum values sets the limits to this CPU goal management. A minimum prevents WLM from taking away resources and maximum prevents WLM giving more even if the workload misses goal.
Scope is sysplex-wide.
Absolute MSU Capping
WLM controlled absolute millions of service units (MSU) capping is similar to PR/SM controlled initial (hard) capping. This is permanent capping controlled by WLM. The difference is that absolute MSU capping is specified in MSUs (DC of LPAR) whereas initial capping (i.e., hard capping) is specified in relative weight.
The limit value is derived from DC and LPAR group capacity. This capping is activated in the parmlib member IEAOPTxx with the option AbsMsuCapping = YES.
The scope is a single LPAR.
Options to Control
The z Systems platform provides tremendous capabilities to ran the large complex commercial workloads. Yet there may be a need to control mainframes for several reasons (e.g., cost, preference to production partition over test, etc.). Whatever the necessity may be, mainframe provides seven different latches for you to control itself.
Hemanth Rama is a senior software engineer at BMC Software. He has 11+ years of working experience in IT. He holds 1 patent and 2 pending patent applications. He works on BMC Mainview for z/OS, CMF Monitor, Sysprog Services product lines and has lead several projects. More recently he is working on Intelligent Capping for zEnterprise (iCap) product which optimizes MLC cost. He holds master degree in computer science from Northern Illinois University. He writes regularly on LinkedIn pulse, BMC communities and his personal blog.