fee has been paid to HP for the type and number of components that are to be activated, RTU codewords are made available through the HP Utility Pricing Solutions portal (http:// www.hp.com/go/icap/portal).
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 were generated.
After the appropriate codewords have been applied to a complex, additional components in the complex may be activated, up to the number of component usage rights granted by the applied codewords. Depending on their 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. Temporary capacity 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 and thus, the new numbers to activate 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, meaning that the change is pending until the next reboot.
•If there are deconfigured (failed) cores, it may be impossible 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
151