Policy guidelines



Consider the following guidelines when working with policies:

  • A policy can manage LPARs and groups that reside on multiple CPCs in a CMP environment.
  • If you intend to run iCap across multiple CPCs in a CMP environment, you must specify the context for the master and agent PASs that you want iCap to manage in the master and agent PAS JCL. 
    For more information, see Specifying-the-context-for-master-and-agent-PASs.
  • All of the LPARs, groups and CPCs that iCap manages must be accessible by the same HMC.
  • BMC does not recommend running multiple master PASs on the same CPC, or in the same CASPlex.

    Important

    For testing purposes, if you want to run multiple masters on a CPC or in the same CASPlex, the following requirements apply:

    • Each master PAS must have a unique SSID and a unique CAS with a matching SSID.
    • The CON=value JCL parameter must be specified for every master and agent PAS that you want to manage.

    Note that an LPAR or capacity group can be managed by only one master PAS.

  • Each CPC requires at least one active LPAR that is running a version 3.0 master or agent PAS. 
  • If you want to run iCap across multiple CPCs in a CMP environment, version 2.0 agents are not supported. You can run version 2.0 agents when iCap is managing only a single CPC.
  • You can define multiple policies and subpolicies for the same set of managed LPARs and capacity groups, but only one of those policies can be active at a time.
  • Policies must have a unique name.
  • Depending on your maintenance level, policies must contain the following entities:
    • (BMC.AMIOPS.SPE2201) applied, at least two managed LPARs, capacity groups, and/or subpolicies. Subpolicies must contain at least two LPARs (individual or group members).
    • (BMC.AMIOPS.SPE2201) not applied, at least two managed LPARs and/or capacity groups. Subpolicies must contain at least two LPARs (individual or group members).
  • iCap does not support IBM z/VM guests, as soft caps are not supported on z/VM guests. iCap supports only LPARs that run on a native IBM z/OS system. Starting an iCap PAS on a z/OS system running as a z/VM guest causes the PAS to terminate immediately.
  • If you move managed LPARs and groups to a different CPC, you must update your policies to reflect this change.

Subpolicy guidelines

Consider the following guidelines when working with subpolicies:

  • A policy can contain multiple subpolicies, but each subpolicy must have a unique name.
  • Subpolicies do not support capacity groups. However, you can include group members in a subpolicy in order to manage them as individual LPARs. For more information, see LPAR and group guidelines.
  • (PTF BQY2794 applied) Subpolicies do not support unmanaged LPARs.
  • Subpolicies must contain at least two LPARs (individual or group members).
  • The MSU limit for a subpolicy (and the sum of subpolicy MSU limits) cannot exceed the main policy's MSU limit.
  • If a subpolicy requires more than its assigned MSU limit, it cannot take additional MSUs from the main policy or another subpolicy.
    Subsequently, the subpolicy LPARs might be capped, even if gray-space MSUs are available in the main policy.
  • Nested subpolicies (a subpolicy within a subpolicy) are not supported.

LPAR and group guidelines

Consider the following guidelines when working with LPARs and groups:

  • On any LPAR, only one PAS (master or agent) can be active at any time.
  • (PTF BQY2794 applied) You can add unmanaged LPARs to the main policy only. 
  • BMC recommends running an active agent on every LPAR that you want iCap to manage. 

    Important

    iCap can function with only one active agent on every managed CPC, however, WLM importance data is not available for LPARs that are running without active agents.  iCap manages LPARs that are running without active agents by priority, instead.


    • If you want to run in manage mode but you are running LPARs without active agents, one of the following conditions must exist in your environment:

      • The master PAS has been running for at least four hours.
      • The LPAR has had an IPL since the master PAS started.

      If neither of these conditions exists, iCap can run only in observe mode.


    • If a policy contains groups and the LPAR members are running without active agents, one of the following conditions must exist:

      • At least one LPAR in the group is running with an active agent.
      • None of the group members are running with active agents, but one of the following conditions exists:
        • The master PAS has been running for at least four hours.
        • Each LPAR in the group has had an IPL since the master PAS started.

      If these conditions do not exist in the iCap environment, iCap can run only in observe mode.

    • (PTF BQY2794 applied) Unmanaged LPARs require active agent.

      Warning

      If there is no agent running on an LPAR, iCap doesn't know the 4HRA of the unmanaged LPARs until the master PAS has been running for four hours. If there is a spike in MSU usage, the MSU limit might be exceeded.

  •  You can include the members of a capacity group in a policy and subpolicy as individually managed LPARs, but the following restrictions apply:
    • You can add group members to a policy, but you must include all of the group members in the policy.

      Important

      • If you add group members to the policy (instead of adding the group itself), iCap manages the LPARs as if they are individual LPARs and not part of the group.
      • If a subpolicy contains group members, the policy must include all of the members of the group. However, the subpolicy does not need to contain all of the members.
      • You can use group members as individual LPARs. For example, you might want to manage group members as individual LPARs in the following circumstance:
        • You are managing a single CPC.
        • There a few LPARs running on the CPC, and they are contained in a group. (A policy definition requires a minimum of two LPARs and/or groups.)

          In this case, you can add individual LPAR members to a policy rather than removing the LPARs from the group.

    • If you add group members to a policy or subpolicy, you cannot add the group itself.
    • If iCap is managing the members of a group and you want to add new LPARs to that group, BMC recommends that you add the LPARs to the policy before you add the members to the group on the hardware management console.
      For more information, see Adding-an-LPAR-to-a-capacity-group-in-the-active-policy.
    • (PTF BQY2794 applied) Unmanaged LPARs cannot be members of capacity groups.
  • (PTF BQY2860 applied) You can include LPARs with absolute capping and absolute MSU capping in a policy, but the following restrictions apply:
    • If an LPAR uses absolute capping, you can add the LPAR to the policy as an managed LPAR. The LPAR can't receive more than the MAXDCGCL or absolute capping value. If the MAXDCGCL is zero or greater than the absolute cap, iCap sets the MAXDCGCL to the absolute capping value.
    • If an LPAR uses absolute MSU capping, you can add the LPAR to the policy as an unmanaged LPAR.
      iCap doesn't change the DC of the LPAR, but the LPAR's MSU usage is included in the MSU limit. 

      Important

      iCap doesn't support capacity groups with absolute capping or absolute MSU capping.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*