User's Manual

Also, note that the number of available sharing rights is adjusted whenever an iCAP codeword
is applied to a GiCAP member system which modifies the number of cores without usage rights
on that member. (RTU and AddOn codewords for cores cause such adjustments.)
If available sharing rights go negative (more in use than were purchased for the Group Manager),
then all groups managed by that Group Manager are out of compliance and all group functions
are restricted until the problem is resolved. The problem can be resolved by purchasing and
applying additional sharing rights to the Group Manager, by purchasing and applying core
usage rights to one or more group members, or by removing one or more group members from
their group.
Groups and the TiCAP Balance
Whenever you have more active cores than the number of core usage rights, the temporary
capacity balance is depleted as a mechanism for tracking noncompliance of the group, even if
TiCAP has not been purchased for or applied to any member of the group. This differs from the
behavior of TiCAP on a complex which is not a member of a group, where TiCAP is decremented
only if TiCAP had been specifically purchased for the complex. Within a GiCAP group, temporary
capacity is used as an additional compliance mechanism to support the high availability features
of a group.
Because group members are automatically considered to be users of temporary capacity, to avoid
unexpected TiCAP depletion in a group, it is important to avoid the situations that cause the
Instant Capacity software to make assumptions that all cores might be active on a remote
nPartition, as described previously in the Temporary Capacity section.
If a member is removed from the group, the TiCAP balance on that complex will continue to be
used as a compliance mechanism (decremented whenever the number of active cores exceeds
the number of core usage rights), unless the TiCAP balance on the system is exactly 0.
Group Compliance
When a group is out of compliance, the group is said to be “locked”. Sharing of usage rights and
temporary capacity between members of the group is not allowed, although members can return
borrowed usage rights or reclaim loaned rights. Members cannot be added to the group, but
members can be removed from the group as long as the members deactivate any cores using
borrowed usage rights and as long as GiCAP is able to reclaim any loaned usage rights.
When such an incompatibility is detected, the GiCAP Group Manager sends email to the local
root account and to the registered contact email address for each member of the group.
Multiple Group Considerations
You can create multiple GiCAP groups, and they can be managed by the same Group Manager
or by different Group Manager systems. Note that if a Group Manager has an associated standby
Group Manager, the standby Group Manager functions as a standby for all the groups managed
by that Group Manager.
A server complex can only be a member of a single GiCAP group at a time. In order to participate
in a different group, it must be removed from its group before being added to the other group.
Sharing rights can never be transferred between two active Group Manager systems. As you
create new groups or add new members to existing groups, you might need to purchase and
apply additional sharing rights to the relevant active Group Manager systems. This is necessary
even if the member has been moved from another Group Manager that now has excess sharing
rights.
Sharing rights can never be applied to a Group Manager with standby status. If a standby Group
Manager is requested to take control, the sharing rights of the former active Group Manager
move to it. If additional sharing rights need to be applied before failing back to the original Group
Manager, they must be purchased specifically for the new active Group Manager system (formerly
the standby Group Manager) and acquired from the portal. Once applied, the new total of sharing
156