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

TiCAP debit fix
A problem was fixed where the temporary capacity balance was erroneously debited in a GiCAP
group. The problem occurred only under unusual timing circumstances.
Changes in Version 10.02 from Version 10.01 (HP-UX)
A problem was fixed where after a reboot of a partition on HP Integrity Superdome 2, the number
of actual active cores was not matching the number of intended active cores for that partition.
Changes in Version 10.01 from Version 10.00 (HP-UX)
• Support for Temporary Instant Capacity (TiCap) on HP Integrity Superdome 2
• Implementation of icapstatus command on HP Integrity Superdome 2.
• Added capability for warning period and out of compliance notifications on HP Integrity
Superdome 2.
Changes in Version 10.00 from Version 9.03 (HP-UX)
• Support for HP Integrity Superdome 2
• Defect fixes for boot time performance of iCAP
Changes in Version 9.03 from Version 9.02 (HP-UX)
• Defect fixes in iCAP daemon and GiCAP database
Changes in Version 9.02 from Version 9.01 (HP-UX)
• Performance improvement in GiCAP
• Defect fixes in group manager and iCAP upgrade process
Changes in Version 9.01 from Version 9.0 (HP-UX)
IPV6 network protocol support
Starting with version 9.01, GiCAP supports the IPV6 network protocol for group managers and
group members. Note that group network access does not have to be homogeneous. A group can
contain a mixture of nodes accessed using either the IPV4 or the IPV6 protocol.
iCAP WBEM provider fix
A problem was fixed where the iCAP WBEM provider returned incorrect values when the nPar
partition ids for a complex were not sequential. This problem was only seen when using a WBEM
tool such as wbemexec. It was not a problem when using the iCAP command line interface. The
problem is fixed in 9.01.
GiCAP database problems fixed
The following two problems were fixed in iCAP version 9.01 that could have resulted in corruption
of the GiCAP database:
• Simultaneous operations involving the borrowing or loaning of core usage rights in a GiCAP
group could result in a corrupt database. The problem only occurred under unusual timing
circumstances.
• Transferring usage rights from a group member to prevent the consumption of temporary
capacity on another group member could result in a corrupt GiCAP database. The problem
only occurred if the Group Manager had intermittent contact with the member donating the
usage rights.
16 Major Changes, New Features, and Requirements of Instant Capacity Version 10.x