| | |
|---|
| | Name of the policy or subpolicy Important The policy name must be unique, and the subpolicy name must be unique within the policy. |
| | Description of the policy or subpolicy (up to 32 characters) |
| | This value has one of the following meanings: - If iCap is executing a dynamic MSU limit (that is, you also specify values for Max MSULIMIT, Inc MSULIMIT, and Adj MSULIMIT), this value is the initial starting MSU limit.
For more information about using a dynamic MSU limit, see Overview-of-dynamic-MSU-limit. - If iCap is not executing a dynamic MSU limit, this value is the maximum allowable MSUs to be consumed collectively by all LPARs and capacity groups that the policy or subpolicy manages.
Possible values are from 1 through 99999. Important (PTF BQY2794 applied) If the policy includes unmanaged LPARs, calculate the Initial MSULIMIT value as follows: <MinManagedMSUs> + <portionOfUnmanagedLparUsage> = <initialMsulimit> - <MinManagedMSUs> is the value specified for the Min Managed MSUs parameter (see the description in this table).
- <portionOfUnmanagedLparUsage> is a portion of the expected usage of the unmanaged LPARs in the policy.
Example - Min Managed MSUs = 400
- There are two unmanaged LPARs in the policy.
Unmanaged LPAR A has a DC of 100. Unmanaged LPAR B has a DC of 50.
In most cases, you can include a portion of the expected usage of the unmanaged LPARs. In this case, you might set the Initial MSULIMIT to 500. |
| | If iCap is executing a dynamic MSU limit, this value is the maximum number of allowable MSUs to be consumed collectively by all LPARs and capacity groups that the policy or subpolicy manages. Possible values are from 1 through 99999. For more information about using a dynamic MSU limit, see Overview of dynamic MSU limit. Important If you specify a value for this parameter, you must also specify values for Inc MSULIMIT and Adj MSULIMIT. This parameter corresponds to the Maximum MSUs Allowed parameter in the iCap reports. |
Inc MSULIMIT (Increment MSU limit) | | If iCap is executing a dynamic MSU limit, this value is the number of MSUs by which the initial MSU limit incrementally increases. When the following conditions exist, the MSU limit increases by this value every ADJTIME (or five minutes if ADJTIME < 5): - At least one LPAR or capacity group is capped.
- The MSU limit is approaching.
- The percentage of low importance work reaches the Adj MSULIMIT value.
For more information about using a dynamic MSU limit, see Overview-of-dynamic-MSU-limit. Important If you specify a value for this parameter, you must also specify values for Max MSULIMIT and Adj MSULIMIT. |
Adj MSULIMIT (Adjusted MSU limit percentage)
| | If iCap is executing a dynamic MSU limit, this is the percentage of low importance work in the policy (or subpolicy) at which iCap starts to increase the MSU limit. When the following conditions exist and the percentage of low importance work reaches this value, iCap starts to increase the MSU limit by the Inc MSULIMIT value: - At least one LPAR or capacity group is capped.
- The MSU limit is approaching.
For more information about using a dynamic MSU limit, see Overview-of-dynamic-MSU-limit . Important Consider the following information: - If you specify a value for this parameter, you must also specify values for Max MSULIMIT and Inc MSULIMIT.
- Ensure that the Low Importance parameter is correctly specified. That is, ensure that the low importance value allows low importance and discretionary work to run in your environment.
|
| | Whether to use Workload Manager (WLM) tuning to determine the order in which LPARs and groups receive MSUs if competing for MSUs when the MSU limit is approaching The order of LPARs and groups is set by the values defined for LPARs and capacity groups in the Low Importance parameter. For more information, see Low Importance parameter. Possible values are as follows: YES MSUs are distributed according to low-importance values and priority. Consider this option when the WLM policies that are managing the workloads are sufficiently different—that is, the importance value of n on one sysplex is not comparable to the importance value of n on another sysplex. For more information, see Using-WLMTUNING-YES. COMBINED MSUs are distributed according to low-importance values. Consider this option when the WLM policies that are managing the workloads are sufficiently similar—that is, the importance values of n must be comparable on each sysplex. iCap includes low-importance values from different sysplexes, as if all systems in the policy belonged to a single sysplex. For more information, see Using-WLMTUNING-COMBINED. NO This option distributes MSUs according to the priority values assigned to LPARs and capacity groups (defined in the Priority parameter), ignoring the low-importance values. For more information, see Using-WLMTUNING-NO.
Warning To use WLM Tuning=YES or WLM Tuning=COMBINED, iCap requires an active agent on every LPAR or LPAR group member that you want to manage. For more information, see Policy-guidelines. |
AdjFac Priority 1 AdjFac Priority 2 AdjFac Priority 3 AdjFac Priority 4 AdjFac Priority 5 | 0.6, 0.8, 1, 1.2, 1.4 (priority 1, 2, 3, 4, and 5 respectively) | Adjustment factors that iCap uses to determine the Adjusted Low Importance Workload Percentage for an LPAR or capacity group The Adjusted Low Importance Workload Percentage determines the order in which LPARs or capacity groups receive MSUs when the MSU limit is approaching (if WLMTUNING= YES or COMBINED). iCap uses the values specified for Adjustment Factors for Priority to calculate the Adjusted Low Importance Workload Percentage as follows: <lowImportanceWorkloadPercentage> × <adjustmentFactors> adjustmentFactors refers to the adjustment values that you set with this parameter. lowImportanceWorkloadPercentage refers to a value that iCap calculates as follows: [<lowImportanceMSUs> / <totalMSUs>] x 100 lowImportanceMSUs refers to any MSUs consumed at the specified importance level. That is, if Low Importance = 4, lowImportanceMSUs is the number of MSUs consumed by any jobs with a workload importance of 4 or lower. The values must increase from priority 1 through 5. Important Consider the following information: - You must specify all of these parameters, or none.
- If you specify AdjFac Priority 1=0 , priority-1 LPARs receive additional MSUs regardless of the WLM setting and whether the LPARs are using dynamic entitlement.
For LPARs running high-priority workloads, you can specify an adjustment factor of 0 for priority 1. In this case, LPARs or groups with priority 1 have an Adjusted Low Importance Workload Percentage of 0 and are favored over all other LPARs and groups. |
| | The workload importance level at which to begin delays if the jobs of that workload surpass the maximum number of allowed MSUs Service class periods that are running in a workload (on an LPAR) have predefined importance values. For example, if you specify 4 for the Low Importance value, all service class periods with an importance value of 4 and below are considered to be low importance. Therefore, if the workload surpasses its maximum number of allowed MSUs, any jobs with a workload importance of 4, 5, or discretionary workloads might be delayed. Valid values are 2, 3, 4, 5, and D (discretionary workloads). Tip On the POLIMP view, you can see the amount of importance work (in MSUs) per importance level that was consumed in the last five minutes for each LPAR and group on the CPC. This parameter corresponds to the Low-Importance Level to Delay parameter in the iCap reports. |
| | Whether to consider the cost limit when distributing MSUs If you specify YES, iCap ensures that the MLC costs incurred by the policy do not exceed the cost limit. This parameter is linked to the MSU Cost parameter, which is specified at the LPAR/group level. For more information, see LPAR-level-and-group-level-parameters. The cost limit for a policy is equal to the sum of cost entitlements for all managed LPARs and groups. Important If a policy contains subpolicies, BMC recommends that you specify the same value for the main policy and the subpolicies. For more information, see Calculating-cost-limit. |
| | Whether to favor LPARs and groups with high-importance workloads when the combined 4HRA exceeds 95% of the MSU limit This parameter enables iCap to assign additional MSUs to LPARs and groups that are running high-importance workloads by taking MSUs from LPARs and groups with a large number of low-importance workloads. iCap distributes MSUs as follows: All LPARs and groups receive enough MSUs to cover their high-importance workloads. Although iCap might still cap LPARs or groups, it distributes enough MSUs to every LPAR to run high-importance workloads, provided enough MSUs are available. - iCap distributes any remaining MSUs according to the low-importance percentage.
Important This parameter is available only if WLM Tuning = Combined. When iCap uses dynamic entitlement, we recommend that every managed LPAR and group have an active agent. An agent collects importance data for an LPAR or group. If an LPAR or group does not have an active agent and the combined 4HRA exceeds 95% of the MSU limit, the LPAR or group is treated as of high-importance and receives its full defined capacity (DC). As a result, iCap might heavily cap other policy LPARs that are running large numbers of low-importance workloads. |
| | Whether to increase the MSULIMIT to reflect a discount from mobile workload transaction reductions This parameter enables iCap to adjust the MSULIMIT based on the number of MSUs used by the 4HRA of mobile workloads. When you specify YES, iCap recalculates the entitlement for every LPAR and Capacity group in the policy based on the new MSULIMIT. |
| | Whether to increase the MSULIMIT to reflect a discount from Container Pricing This parameter enables iCap to adjust the MSULIMIT based on the number of MSUs used by the 4HRA of container workloads. When you specify YES, iCap recalculates the entitlement for every LPAR and Capacity group in the policy based on the new MSULIMIT. Important You need to identify which LPARs are included in the container. For more information, see the following topics: |
Unmanaged LPARs (PTF BQY2794 applied) | | Whether there are unmanaged LPARs in the policy Important If you specify YES, you must also specify a value for Min Managed MSUs. |
Min Managed MSUs (PTF BQY2794 applied) | | Minimum number of MSUs that are reserved for the managed LPARs and groups in the policy Consider the following information: - These MSUs are available only for the managed LPARs. The unmanaged LPARs cannot use these MSUs.
- To determine this value, consider the minimum number of MSUs that the managed LPARs require. If you are building a policy for the first time, you can set this value to the sum of combined 4HRAs for all of the managed LPARs.
- Depending on the MSU usage of the unmanaged LPARs, the managed LPARs might receive more than the Min Managed MSUs. That is, the MSUs used by the unmanaged LPARs are subtracted from the current MSU limit. The remaining MSUs are distributed to the managed LPARs as required.
Example The policy has an MSU limit of 1,200 and the Min Managed MSUs is 1,000. There is one unmanaged LPAR in the policy with a DC of 250: - The unmanaged LPAR can use a maximum of 250 MSUs.
- The managed LPARs can use a maximum of 1,200 MSUs depending on the MSU usage of the unmanaged LPARs.
Therefore, if the unmanaged LPAR requires 100 MSUs, the managed LPARs can use a maximum of 1,100 MSUs. If the unmanaged LPAR requires more MSUs (up to 250), there are fewer MSUs available for the managed LPARs. For more information, see Managed-and-unmanaged-LPARs. Important If iCap is running a dynamic MSU limit and iCap increases the main policy's Initial MSU limit, the Min Managed MSUs value also increases. Example The following values are specified in a policy: - Initial MSULIMIT=600
- Max MSULIMIT=1021
- Inc MSULIMIT=50
- Adj MSULIMIT=95
- Min Managed MSUs=400
- Unmanaged LPARS=YES
If the percentage of low importance work in the policy reaches 95%, iCap starts increasing the main policy's Initial MSULIMIT and Min Managed MSUs by 50 every ADJTIME (or five minutes if ADJTIME < 5). The number of MSUs available to the unmanaged LPARs (their DC) does not increase. For more information, see the descriptions in this table for Inc MSULIMIT and Adj MSULIMIT.
|
| | (Policy-level only) Pricing model by which to manage the policy Valid values are as follows: - Monthly License Charge (MLC) manages DCs and GCLs in relation to the 4HRA and MSU limit
Tailored Fit Pricing (TFP) manages the absolute capping values in relation to the 4HRA and MSU limit. Important - TFP mode does not support capacity groups.
- If you are running in manage mode and want to switch to a different management mode, you must restart the PAS with a different policy. For example, if the PAS is running with Policy A in TFP mode, you cannot change the management mode of the policy to MLC. To change the mode, restart the PAS with a different policy that uses MLC management.
- If you are running in observe mode with NO-POLICY specified, you can activate a TFP or MLC policy.
Tip If you are running iCap in TFP mode, the value that you set for the policy MSU limit requires careful consideration and an understanding of the objective you are trying to achieve. In TFP mode, every MSU counts towards your bill. You might want to prevent your CPC from getting too busy and consuming more MSUs for a given workload. To maintain efficiency, you could set an MSU limit value that restricts MSUs usage to 80% of your total MSUs. Alternatively, if you don’t want to exceed a certain amount of MSU usage, you could set the MSU limit to that value. This might be relevant if you have a large machine to allow for growth, but you aren’t ready to use the entire capacity of the machine.
|
| | Designates the LPARs whose low-importance work is considered when calculating the low-importance workload percentage to determine if iCap needs to increase MSU limit. Valid values are from 1 through 5. Any LPARs whose priorities are less than or equal to the Scope parameter value are used to calculate the low-importance workload percentage. iCap uses this percentage to determine whether it is necessary to increase the MSU limit. Example If Scope = 2, LPARs whose priority is 1 or 2 is included while calculating the low-importance workload percentage. LPARs with priorities 3, 4, and 5 are excluded from the calculation. |