Displaying an overview of the active policy

This value has one of the following meanings:

• If iCap is executing a dynamic MSU limit, this is the initial starting MSU limit. For more information about using a dynamic MSU limit, see Overview-of-MSU-limit-CPCMSU-limit-and-cost-limit.
• If iCap is not executing a dynamic MSU limit, this value is the maximum MSU limit for the active policy.

Mode in which iCap is running

If iCap is executing a dynamic MSU limit, this is the maximum number of allowable MSUs to be consumed collectively by all LPARs and capacity groups that the policy or subpolicy manages.

For more information about using a dynamic MSU limit, see Overview-of-MSU-limit-CPCMSU-limit-and-cost-limit .

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.

For more information about using a dynamic MSU limit, see Overview-of-MSU-limit-CPCMSU-limit-and-cost-limit .

Scope

(BMC.AMIOPS.SPE2301)

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.

For more information, see Scope.

Number of MSUs saved over the current month

This field displays the number of MSUs that iCap has saved during the current month by capping LPARs that would otherwise have exceeded their DCs, and therefore cause the LPARs in the policy to exceed the MSU limit. This number can change due fluctuations in MSU usage over the month.

Whether iCap is considering the cost limit when distributing MSUs

If iCap is executing a dynamic MSU limit, this is the number of MSUs by which the MSU limit incrementally increases (every ADJTIME) if the policy is unable to run low importance workloads.

For more information about using a dynamic MSU limit, see Overview-of-MSU-limit-CPCMSU-limit-and-cost-limit .

Number of MSUs saved in the previous month

This field displays the number of MSUs that iCap saved in the previous month by capping LPARs that would otherwise have exceeded their DCs, and therefore cause the LPARs in the policy to exceed the MSU limit.

Type

Possible values are:

• P — subpolicy
• G — group
• L — LPAR
• U — unmanaged LPAR
• I — group member (also known as individual LPAR)
• A — available MSUs (MSUs that aren't being used by the policy or subpolicy)
• R — reserved MSUs (MSUs that are reserved for LPARs or groups that might be down)
• T — entire policy

Individual LPARs are members of capacity groups and are being individually managed by iCap. That is, iCap manages the LPARs individually instead of as a group. The Group Name field shows the group to which the LPAR belongs.

During the recent sample, the percentage of elapsed time that the LPAR or group was capped

For LPARs with active agents, this value represents capping over the previous 1-minute sample. (BMC.AMIOPS.SPE2201) For LPARs at sample time, this value represents 100% capping.

Percentage of low importance work running on an LPAR or group

Alarms alert you when the value in this field reaches 5% and 0%.

(BMC.AMIOPS.SPE2110) In MainView Explorer, a hyperlink on this field links to the SUs by Importance chart for the selected LPAR or group. For more information, see iCap-charts-in-MainView-Explorer.

Adjusted Low-Importance Workload Percentage

If WLM Tuning is specified as YES or COMBINED, iCap considers the Adjusted Low-Importance Workload Percentage to determine the order that LPARs and groups will receive MSUs when they are competing for MSUs when the MSU limit is approaching.

The Adjusted Low-Importance Workload Percentage is calculated as follows:

Reason that iCap cannot manage an LPAR or group

Possible values are:

• H — The LPAR is hard-capped or MSU Absolute Capping is active.
• W — Wait completion is active
• D — Dedicated processors for LPAR
• M — The LPAR is missing (not found in the DIAGNOSE buffer)
• U — The 4HRA of the LPAR is unknown.
• N — The LPAR is not active.
• G — The LPAR belongs to a group that is also specified in the policy/subpolicy. The LPAR is excluded; iCap manages the group.
  
  

Status of the LPAR or group

Possible values are:

• OK

• Warn

  A warning status indicates that one of the following conditions exists:

  • The LPAR or group is missing (is not found in the DIAGNOSE buffer).
  • The LPAR is not active, or at least one LPAR member of a group is not active.

• Error

  An error status indicates that one of the following conditions exists:

  • The LPAR is running without an agent, or at least one LPAR member of a group is running without an agent.

    Important

    For an LPAR, the value of the # of Agents field is 0. For a group, the value is less than the # Members. To view information about the LPAR members in the group, hyperlink on the # Members field for a group to access the GRPMEM view. Use the Status column on GRPMEM to identify any LPARs that are running without agents.

  • The LPAR or group is hard capped.
  • Wait completion is enabled on the LPAR.
  • The LPAR uses dedicated processors.

Name of the sysplex where an LPAR or group is running

Name of the group to which an individual LPAR belongs

Number of MSUs to which an LPAR or group is currently entitled

When dynamic entitlement is enabled this field displays the adjusted entitlement for an LPAR or group, or the lesser of entitlement and adjusted entitlement. That is, if the calculated adjusted entitlement value is less than current entitlement, this field displays the adjusted entitlement value.

For more information, see the Dynamic Entitlement parameter description in Policy-level-and-subpolicy-level-parameters.

The subsystems that are running on an LPAR or group

Possible values are:

• D— Db2
• C— CICS
• W— WebSphere Transaction Manager
• I— IMS
• M— IBM MQ (formerly called IBM WebSphere MQ)

(BMC.AMIOPS.SPE2210)

Absolute Cap