Most teams license production carefully and treat disaster recovery as an afterthought, on the assumption that a machine sitting idle does not need a license. IBM's view is more specific. The obligation turns on what the standby environment is actually doing, not on whether it is the primary. The terms distinguish between standby that is genuinely dormant and standby that is installed, running, or ready to take load, and those distinctions decide whether PVU is owed.
Cold, warm and hot standby are not the same to IBM.
The three categories describe how ready a recovery environment is to take over, and IBM's standby and backup provisions treat them differently:
- Cold standby. The recovery machine is off, or the software is not installed and not running, until a disaster is declared. This is the category IBM's backup provisions are most likely to accommodate.
- Warm standby. The software is installed and the environment is partially running or synchronizing, ready to be brought up quickly. This typically carries a licensing obligation.
- Hot standby. The environment is installed, running and able to take production load at once, often in active replication. This is generally treated as licensable like production.
The exact treatment depends on your specific Passport Advantage and product terms, so the category has to be matched against your agreement rather than assumed.
Idle does not always mean unlicensed.
The word idle does a lot of unearned work in DR planning. A server can be idle in the sense that no users are on it, while the IBM software is installed and running, ready to fail over. For licensing, installed and running usually counts even if the workload is zero, because the entitlement attaches to the capacity made available to the software, not to the number of transactions it happens to be serving. The safest assumption is that anything beyond genuinely cold standby is in scope until your terms say otherwise.
The Power LPAR trap.
Virtualization rules differ by hypervisor, and disaster recovery on Power is where idle capacity bites hardest. On Power LPAR, the count is based on the cores allocated to the partition even if those cores sit idle. A recovery LPAR sized to absorb full production therefore counts at its allocated size, not at its actual utilization. A DR partition built generously for headroom can carry a PVU figure that rivals production, entirely on capacity that has never served a request.
Building a defensible DR position.
A clean DR position starts by classifying every recovery environment as cold, warm or hot against the real configuration, not the label on the runbook. From there it maps installed and running software to entitlements, checks allocated cores on Power and other architectures that count idle capacity, and confirms that anything relying on a backup provision genuinely meets the dormant standard. Where a server has been treated as free but is actually warm or hot, it is better to find that internally than to have it surface as an audit finding with back charges attached.