User's Manual

member system needs to be activated, the usage rights made available by the deactivated
component can be taken by the system using temporary capacity. In this case you might need
to use the -t option to the icapmodify command to activate the component on the third member
system by using temporary capacity.
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.
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.
Status Reporting
Usage rights and temporary capacity can sometimes be temporarily assigned to the Group
Manager, which can result in difficulty interpreting some of the data from the icapstatus
command. The total temporary capacity reported for the group by icapmanage -s might not
equal the sum of temporary capacity reported by each member system. This is because the Group
Manager prefetches an amount of temporary capacity in anticipation of needing it for a future
operation, so the temporary capacity might not be immediately assigned to a member system.
Also, individual counts of cores, cells, and memory without usage rights for each member of the
group might not add up to the total counts of cores, cells, and memory without usage rights for
the group. In all cases, totals reported (by icapmanage -s) for group temporary capacity and
usage rights are the important values that represent available resources for the group. Use the
verbose (-v) option to the icapmanage -s command to see resources held by the Group
Manager.
The icapstatus command reports usage rights borrowed or loaned by the system from or to
other members of the group. Borrowed rights are those that are currently resident on the member
and that originated elsewhere. Loaned rights originate on the system but are currently resident
somewhere else in the group. They might be either in use or unassigned on another group
member, or they might be unassigned on the Group Manager itself. The icapmanage -s
command displays the status of the entire group, while the icapstatus command displays an
isolated view of a single member.
Unassigned usage rights are free to be moved to other member systems, even if a particular
activation request fails. For example, consider a group where there are no free usage rights. If
member m1 releases 2 core usage rights by deactivating 2 cores, and member m2 tries to activate
3 cores, the activation request fails (not enough usage rights), after the Group Manager has
already migrated 2 core usage rights from m1 to m2. The borrow and loan values for m1 and m2
show that the loan has occurred, even though the activation on m2 failed to activate any cores.
A subsequent activation of 2 cores on m2 will be successful and will occur more quickly because
the 2 core usage rights are already assigned to m2, or because the rights are moved elsewhere in
the group if requested.
Global Instant Capacity Resource Sharing 113