HP Instant Capacity release notes for Version 10.x (March 2011)

even if temporary capacity has never been purchased or applied; it means that the system has
gone out of compliance.
Also, if Temporary Capacity is negative and the number of active cores exceeds the number of
core usage rights for the complex, at boot time automatic deactivation of cores may occur. This
“boottime enforcement” to maintain compliance is not new, although previously there were gaps
in enforcement which have now been fixed. This enforcement now applies to all systems, whether
or not temporary capacity has been applied.
Changes in the Application of RTU Codewords
A negative TiCAP balance is no longer cleared when applying an RTU codeword.
Also, improvements were made to the application of RTU codewords on GiCAP group members.
With this release, the amount of core usage rights on a member cannot be more than the sum of
the “number of cores without usage rights” and “borrowed core usage rights.”
Improvements in TiCAP Transfer Between GiCAP Group Members
Improvements were made to the transfer of TiCAP between GiCAP group members. The flow of
TiCAP between group members was improved so that all TiCAP-consuming GiCAP members enter
their TiCAP warning period at approximately the same time and all TiCAP-consuming group
members will run out of TiCAP at the same time.
Reboot error with GiCAP members
When GiCAP members were rebooted, under some circumstances there was a startup error message
indicating that the complex was not a member of any GiCAP group. This problem is fixed.
Changes to icapmanage
The icapmanage -s -v option was modified to show additional information including resources
held by the Group Manager, borrow/loan values for group members, and unassigned usage rights
available across the group.
A new option, icapmanage —u -m <member name> —h <hostlist>, was added to provide
host-level operations to icapmanage allowing hosts to be added to or removed from an existing
GiCAP group.
Changes to the GiCAP Database
iCAP version 8.02 GiCAP Group Managers store more information about the members of a group.
This information must be fetched from the various group members when converting an earlier
version of the GiCAP database to the current version. This information cannot be fetched if all hosts
of a GiCAP Group member cannot be contacted. Therefore, HP recommends updating a GiCAP
Group Manager system to iCAP version 8.02 or later only when every GiCAP Group Member
has at least one host which can be contacted by the GiCAP Group Manager.
Additional improvements were made to the error handling on GiCAP database write errors.
Previously, a write error may have resulted in incorrect gain or loss of usage rights within the group.
Improved GiCAP Logging
GiCAP logging was improved with this release. The GiCAP log file /var/adm/GiCAP.log
includes logging for events such as usage rights transfers, TiCAP transfers, usage rights releases
and compliance events.
Adding non-iCAP systems to a GiCAP Group
In previous releases, iCAP would not authorize the activation of a core on a vPar with an Intended
Active count of zero. This is fixed, and adding a complex with no iCAP components to a group is
now permitted.
Summary of New Features and Changes 21