WebSphere PVU reconciliation: a worked example.
PVU reconciliation sounds abstract until you put real cores and a real entitlement against it. This worked example walks a WebSphere estate from raw processor counts through sub-capacity to the entitlement comparison, so you can see exactly where a finding grows and where it can be argued back down.
Every WebSphere audit number is built the same way: count the cores, apply the PVU rate, decide whether sub-capacity holds, then compare the result to what you own. The figures below are illustrative, chosen to show the mechanics rather than to describe any specific engagement. The point is to make visible the steps where the count quietly inflates and where a buyer side reconciliation pulls it back.
Step one: the raw core count
Take a WebSphere estate running across three hosts. Each host has 32 Intel cores. WebSphere is deployed on virtual machines using 8 cores on the first host, 4 on the second, and 4 on the third, for 16 cores actually carrying WebSphere across the estate. The physical total across all three hosts is 96 cores. That gap between 16 and 96 is the entire reconciliation in miniature.
Step two: apply the PVU rate
Intel cores in this class are valued at 70 PVU per core. The honest sub-capacity figure is the 16 WebSphere cores at 70 PVU, which is 1,120 PVU. The full-capacity figure, applied if sub-capacity does not hold, is the 96 physical cores at 70 PVU, which is 6,720 PVU. Same software, same deployment, a six fold difference driven entirely by whether the sub-capacity conditions are met.
1,120 PVU sub-capacity versus 6,720 PVU full-capacity. The 5,600 PVU difference is not over-deployment. It is the cost of an eligibility condition that was not satisfied or not evidenced. This is the gap that most WebSphere findings actually represent.
Step three: test whether sub-capacity holds
Sub-capacity at 1,120 PVU only stands if the IBM License Metric Tool was deployed within 90 days of first eligible deployment, ran continuously, recorded these virtual machines correctly, and the quarterly reports were retained for two years. If the tool missed one host for a quarter, that host's WebSphere reverts to full-capacity for the affected period, and the count climbs partway back toward 6,720 even if the other two hosts stay clean.
Step four: compare to entitlement
Now bring in what you own. Suppose Passport Advantage records show 1,400 PVU of WebSphere entitlement. Against the sub-capacity figure of 1,120 PVU, you are compliant with headroom to spare. Against the full-capacity figure of 6,720 PVU, you are short by 5,320 PVU, and that shortfall is what would land in a compliance gap letter. The entire dispute therefore turns on restoring sub-capacity, not on buying licenses.
- Confirm the 16 core WebSphere count is correct and no instances were missed or double counted.
- Recompute every core at the right PVU rate for its exact processor, not a generic assumption.
- Rebuild the ILMT evidence to hold sub-capacity for each host and period.
- Credit the full entitlement, including any offsets IBM omitted, against the reconciled figure.
A WebSphere PVU finding is usually the distance between sub-capacity and full-capacity, not genuine over-deployment. Reconstruct the real core count, hold sub-capacity with ILMT evidence, and set the result against your full entitlement. In this worked example a 5,320 PVU shortfall collapses to compliance once sub-capacity is restored. The reconciliation is where that happens.