HP Instant Capacity Version 10.x User Guide (762794-001, March 2014)

Instant Capacity codewords (such as RTU codewords) are applied to a complex using the
icapmodify command on any partition of the complex. iCAP codewords are generated with a
sequence number, and all iCAP codewords for a particular complex must be applied in the order
in which they are generated.
After the appropriate codewords are applied to a complex, additional components in the complex
may be activated, up to a maximum number of component usage rights granted by the applied
codewords. Depending on its type, components are activated using the icapmodify command
(if activating cores), or other commands including parmodify (see parmodify(1M)) and parmgr
(see parmgr(1M)).
In addition to RTU codewords, cores can be activated with temporary capacity. TiCAP codewords
allow the activation of more cores than allowed by the usage rights on the complex, but only for
a limited time.
Software removal
Instant Capacity software cannot be removed. Other software products depend on it to approve
configuration changes to the system.
Status of Instant Capacity components
Information about the Instant Capacity components on a complex and the available usage rights
for each type of component can be obtained by invoking the icapstatus command. This
command also provides information about the amount of temporary capacity presently in use, the
projected expiration of the temporary capacity, and counts of active and inactive components.
One status field that is important to understand is the intended active (IA) value for each
nPartition. Fundamentally, the intended active value is the number of cores intended to be
active after a reboot. As processing needs change, the IA value is modified by commands like
icapmodify, parcreate, and parmodify to represent the new distribution of active cores
across the nPartitions. The same numbers of cores are activated on reboot of the nPartitions.
Note that the status field intended active can differ from the status field actual active (AA) in
some cases, including the following:
• In an nPartition, activations or deactivations can be deferred, that is the change is pending
until the next reboot.
• If there are deconfigured (failed) cores, it might be not possible for the nPartition to reach the
configured IA value. The IA value is not affected by deconfigured cores, but the AA value
may be lower in this case.
• In a virtual partition, core assignments can be increased or decreased with either the
icapmodify command or the vparmodify command, but only icapmodify changes the
intended active for the nPartition. vparmodify activation commands are constrained by the
intended active value, but deactivation commands are allowed to deactivate below IA, so
that the number of cores actually assigned to all the virtual partititons of the nPartition
(represented by the AA status field) may be less than the IA value for the nPartition. This results
in something called “unused capacity”; but typically happens only during the window of time
that resources are being shifted across the virtual partitions of an nPartition. Overall, this
mechanism allows for quicker shifting of resources within virtual partitions.
If the complex is a member of a GiCAP group, the icapstatus command provides information
about group membership, including any borrow or loan status of usage rights. Detailed information
about GiCAP groups can be obtained by invoking the icapmanage -s command on a Group
Manager system.
Virtual partitions
Instant Capacity has a minimum version dependency on vPars A.03.05. For versions of vPars
before A.03.05, the icapmodify command for activating or deactivating cores in a virtual
partition fails with an error message indicating the vPars version dependency.
144