Db2 PVU reconciliation: a worked example.

The opening claim, and what it assumes.

Picture a Db2 Advanced Enterprise Server Edition deployment that IBM's audit team scores at full capacity. The database runs in a VMware cluster of four hosts, each with two sockets of sixteen cores, so the cluster holds 128 physical cores. At roughly 70 PVU per Intel core, IBM's opening position multiplies all 128 cores by 70 and arrives at 8,960 PVU. That number is only correct if you have no defensible sub-capacity claim. The reconciliation tests whether that assumption holds.

Step one: establish sub-capacity eligibility.

Sub-capacity licensing lets you license only the virtual cores running Db2 rather than the whole cluster, but only if ILMT (or an approved tool such as HCL BigFix Inventory or Flexera One ITAM) was deployed within ninety days of first eligible use, has run continuously, and produced quarterly reports retained for two years. The first move is to confirm those conditions held across the audited period. Where ILMT was present and clean, IBM's full-capacity figure is not the number you owe. Where there are gaps, we scope them precisely rather than conceding the whole window.

• Confirm ILMT was live within ninety days of first Db2 deployment
• Confirm continuous operation, with no agent outages voiding a quarter
• Pull the quarterly sub-capacity reports for every period in scope
• Identify the peak virtual core consumption Db2 actually drew

Step two: count the cores Db2 actually used.

With sub-capacity established, the count drops from the cluster to the virtual machines Db2 ran on. Say Db2 was pinned to two virtual machines of eight virtual cores each, sixteen virtual cores in total, and ILMT confirms that peak. Sixteen cores times 70 PVU is 1,120 PVU, not 8,960. That is the sub-capacity entitlement requirement. The reconciliation does not stop there; it checks whether VMware vMotion could have let Db2 roam across hosts, because uncontrolled mobility can pull the whole cluster back into scope unless it was correctly restricted.

What this means under audit.

The gap between 8,960 PVU and 1,120 PVU is the entire dispute, and it is won on evidence, not assertion. Under Contain, Reconcile, Challenge, Settle, the Reconcile step rebuilds this number from clean ILMT data and host affinity rules, and the Challenge step puts the rebuilt figure in front of IBM with the records behind it. A worked reconciliation turns an opening claim into a defensible position, and that is what moves the settlement.