LPAR sets
Some installations have requirements for which Defined Capacity or LPAR Group Limits are not sufficient. For example:
- Define a limit on a group of LPARs without implementing soft capping.
- Establish separate limits for various subsets of LPARs based on the differing sets of software products that they run. Some LPARs might belong to more than one subset.
- One or more LPARs must not be capped but their usage should be included in R4HA calculations. Some LPARs may be hard capped and therefore cannot be subject to Defined Capacity or LPAR Group Limits.
- The installation makes use of Country Multiplex Pricing (CMP) and wants to control batch workload based on an overall limit for the R4HA across multiple CPCs on any or all JESplexes in all of the Sysplexes in the multiplex.
- The installation takes advantage of Mobile Workload Pricing or has public cloud workloads.
- The installation uses Tenant Resource Groups to implement Colocated Containers for software pricing.
ACM enables the installation to define subsets of the z/OS LPARs on each CPC as named LPAR Sets and assign a R4HA limit to each LPAR Set. On each LPAR on which ACM is active, ACM monitors and calculates the R4HA for each defined LPAR Set to which the LPAR belongs.
LPAR Sets can be used whether or not the installation has specified Defined Capacity or LPAR Group Limits. ACM will automatically determine all the applicable LPAR Set limits for each LPAR and factor these into its calculations. Note that an LPAR Set limit being reached does not cause soft capping to occur.
An LPAR Set may also be defined as a Multiplex LPAR Set. When specified, ACM will total the R4HA on every CPC in all JESplexes in the Sysplex on which the LPAR Set is defined with the identical name and compare that total usage against a specified overall Multiplex limit.
Note that a Multiplex LPAR Set must be defined with the same name in all JESplexes in all Sysplexes.
In order for ACM to correctly identify each instance of the Multiplex LPAR Set, it must be defined with the same name in each active SLM Policy on each JESplex in the multiplex.
If you are uncertain as to what value to use for the limit for a given LPAR Set, you can specify zero. While ACM will monitor the LPAR Set and calculate the R4HA, it will take no actions based on the R4HA for the LPAR Set while the limit remains zero. BMC Compuware ThruPut Manager provides operator commands as well as SMF records that allow you to monitor the R4HA for all LPAR Sets, providing information that will prove useful in setting a limit value. This applies to both regular and Multiplex LPAR Set limits. You may wish to always leave the regular LPAR Set limit at zero and set only a Multiplex limit.
When defining a Multiplex LPAR Set in multiple SLM Policies across multiple JESplexes, you must ensure that for each CPC, the same LPARs are defined as belonging to the LPAR Set and that the overall Multiplex limit for the LPAR Set is the same. If there are differences between the definitions for one or more JESplexes, ACM will issue messages every 15 minutes that indicate either a difference in LPARs defined for the LPAR Set on an indicated CPC, or that the limits are inconsistent.
If there is a conflict in the limit specified for a given LPAR Set, ACM will use the limit from the most recently updated SLM Policy. This is designed to accommodate the adding a new CPC to a sysplex. When this occurs, you may wish to increase the limit for the affected LPAR Sets. Just set the new limit in the SLM Policies for the JESplexes that are on the new CPC, and ACM on the other JESplexes will automatically use the new limit. They will issue warning messages every 15 minutes and when you have time you should update those policies as well.
Using Multiplex LPAR Sets across Sysplexes
Within a sysplex, ACM uses XCF to exchange LPAR Set usage data between JESplexes and therefore requires no additional configuration.
However, ACM uses TCP/IP to communicate between JESplexes that are on different sysplexes. Therefore, in addition to the normal z/OS TCP/IP configuration requirements, you will need to supply additional 'TM TCPIP' TMSS initialization statements.
You need to identify the port number to be used by the local ThruPut Manager to receive messages (TM TCPIP SET PORT) as well as provide at least one IP address and port number for every JESplex on another sysplex with which ACM will exchange information on LPAR Set usage (TM TCPIP ADD). It is strongly recommended that you supply this information for every member of every JESplex so that ACM can still communicate as long as one member in a JESplex is up.
See the ThruPut Manager Base Product System Programming space for details on the TM TCPIP SET and TM TCPIP ADD statements.
You can also use TM TCPIP commands to supply information on remote JESplexes dynamically until you have the opportunity to restart ThruPut Manager. See the ThruPut Manager Command Reference space for details.
Note: The port number for the local ThruPut Manager to use to receive messages can only be supplied using a TMSS initialization statement (TM TCPIP SET PORT). It cannot be set via command.
Mobile and Public Cloud Workload Pricing Discounts
ACM supports discounting the mobile and public cloud contribution to the R4HA of any Multiplex LPAR Set as specified in the following IBM pricing options: Mobile Workload Pricing (MWP) and Z Workload Pricing for Cloud (ZWPC).
You must specify in the SLM Policy that you want to activate discounting for mobile and/or public cloud.
When discounting is activated, for every Multiplex LPAR Set, ACM will automatically accumulate the R4HA and 5 minute interval consumption rate for all workload classified by WLM as “MOBILE” or “CATEGORYA” (public cloud), and then subtract 60% of the accumulation from the R4HA and 5 minute interval consumption rate totals for the LPAR Set.
This enables you to set the limits for each LPAR Set to your desired targets based on the discounted peak values that are reported by the SCRT. ACM will automatically consider the amount of mobile and pubic cloud workload when determining how much batch workload can be run given each LPAR Set limit. This means that the same limit applies all the time, regardless of how much mobile or public cloud workload may be running.
Note that, in order to obtain complete information on mobile and public cloud workload consumption, ThruPut Manager with ACM enabled must be running on all z/OS LPARs.
This support is only available for Multiplex LPAR Sets as it relies on information being exchanged between LPARs that may not be in the same JESplex or Sysplex. ACM only exchanges this information for Multiplex LPAR Sets. ACM will add up the mobile and public cloud workload usage rates across all LPARs on all CPCs.
However, it is not necessary to use Country Multiplex Pricing to take advantage of support for discounting workloads. By giving each Multiplex LPAR Set a name that is unique to each CPC, the discounts and usage will be totaled across LPARS on the same CPC only.
Excluding Tenant Resource Groups
ACM automatically deducts from the R4HA and interval consumption of every applicable Multiplex LPAR Set, the total R4HA and 5 minute interval consumption rate for all workload classified by IBM as belonging to Tenant Resource Groups.
This enables you to set the limits for each Multiplex LPAR Set to your desired targets exclusive of the load in the Tenant Resource Groups (sometimes called "Colocated Containers"), mirroring what will be reported by the SCRT. This means that the same limit applies all the time, regardless of how much workload may be running in Tenant Resource Groups.
Note that in order to obtain complete information on Tenant Resource Group consumption, ThruPut Manager with ACM enabled must be running on all z/OS LPARs.
As with mobile and public cloud discounting, ACM support for excluding workload in Tenant Resource Groups is only available for Multiplex LPAR Sets as it relies on information being exchanged between LPARs that may not be in the same JESplex or Sysplex. ACM only exchanges this information for Multiplex LPAR Sets.
It is not necessary to use Country Multiplex Pricing to take advantage of support for excluding workload associated with Tenant Resource Groups. By giving each Multiplex LPAR Set a name that is unique to each CPC, the R4HA and interval usage for the Tenant Resource Groups will be totaled across LPARs on the same CPC only.
Reducing R4HA without soft capping
If your datacenter does not wish to enable soft capping, you can still benefit from ACM and enabling the R4HA Limit Type.
By defining LPAR Sets, each with their own limit and/or Multiplex limit, you provide ACM with the information needed to calculate the Capacity Level and constrain batch workload based on the active BMC Compuware ThruPut Manager Policy.
If you wish to establish a R4HA limit for each LPAR, you can supply one in the BMC Compuware ThruPut Manager Policy using the dialog. Note that these limits for each LPAR are ignored if either Defined Capacity or an LPAR Group Limit is defined using the HMC.
So even without either a Defined Capacity or LPAR Group Limit being specified, if the R4HA Limit Type is enabled, ACM still calculates the Capacity Levels using LPAR Set limits and any LPAR limit that has been supplied in the BMC Compuware ThruPut Manager Policy. ACM then will constrain batch work using the constraints you have specified for the Capacity Level.
Reducing MLC charges
After some experience with using the R4HA Limit Type, you may consider reducing your Defined Capacity, LPAR Group Limits and/or LPAR Set Limits, and so reduce your monthly software licensing charges, while ensuring your online and high importance batch work is not affected adversely.
For further details regarding the technical aspects of ThruPut Manager processing in a sub-capacity pricing environment, see the Automated Capacity Management Technical Background white paper, available upon request.
BMC Compuware ThruPut Manager and third party capping products
You may already have a third party capping product installed that is continually adjusting the Defined Capacity limit for each LP(s)AR and/or the LPAR Group Limit.
In order for ACM to work with these third party capping products when the R4HA Limit Type is enabled, you provide extra information in the BMC Compuware ThruPut Manager Policy.
If a third party capping product is changing the Defined Capacity and/or LPAR Group limit frequently, ACM can no longer use the limits for comparison. Instead, using the BMC Compuware ThruPut Manager dialog, you set options in the policy to tell ACM to ignore the limits being adjusted by the third party product.
ACM will then use LPAR Set limits and individual LPAR limits set in the policy to determine the Capacity Level, allowing ACM to continue to reduce the R4HA by constraining the batch workload as you have specified in the policy. If the third party capping product only changes the Defined Capacity, then ACM can also continue to track the usage for an LPAR Group if defined.
Contact BMC Support for assistance in configuring ACM to coexist with a third party capping product.
ACM Supports Estimated Time to Capping
On z/OS 2.3 and higher systems, ACM supports the estimated time to capping values calculated by WLM. These are WLM's approximation of when soft capping will begin either for the LPAR or the LPAR Group.
When the estimated time is less than the lead time value supplied in the RTCapLeadTime parameter in the active IEAOPTxx member of the z/OS PARMLIB, if enabled in the active SLM Policy, and if the R4HA Limit Type is enabled, ACM will force the Capacity Level value to 1. This will activate the maximum constraints on batch workload specified by the installation in the active SLM Policy.