Mainframe DR Licensing: Hot, Warm, Cold.

Disaster recovery sites are not licensed by where they sit or what you call them. They are licensed by classification, and the classification turns on two questions: how quickly the standby can take over, and whether it can access production data. Publishers, IBM among them, group standby systems into hot, warm, and cold, and attach very different licensing consequences to each. The same physical machine can be license free or fully chargeable depending on how it is configured and used, which is why DR is one of the most common places to find both unintended exposure and recoverable overspend.

The default matters. Vendors commonly treat an unclassified standby as hot, the most expensive reading, unless you can demonstrate it meets the warm or cold criteria. The burden of proof sits with the buyer. That makes documentation, not just configuration, part of the licensing position.

Directional summary of how the three classifications commonly behave. Specific terms vary by publisher and contract, so treat this as the decision frame, not the contract language.

Directional patterns, not contract terms. The production instance must be fully licensed in every case, and publisher criteria apply.

The boundary that matters most is between warm and hot, because it is the easiest to cross by accident. A warm site that begins continuously replicating and serving production data, or that can be accessed concurrently, has become hot in substance even if the runbook still says warm. After a declared disaster, vendor terms commonly allow the recovery system to carry production for a bounded window, with seventy days appearing in some IBM disaster recovery policy documentation, after which entitlements must be acquired on the recovery system. A disaster is usually defined narrowly as a data center rendered inoperable by an external force, not an ordinary outage, so the provision does not stretch to cover routine failures.

DR exposure surfaces in an audit more often than anywhere else, because the gap between the documented classification and the operational reality is so easy to open. A warm site drifts to hot as data replication is tightened for better recovery objectives. A DR test activates Capacity on Demand without confirming the test provisions, creating a chargeable event out of a rehearsal. An undocumented standby is assumed hot by the auditor because nothing proves otherwise. In each case the cost is not a new purchase decision, it is a reclassification of something you already own, which is why it lands as a surprise.

Classify deliberately and prove it. Document each standby against the warm or cold criteria, and keep the evidence current as recovery objectives change, since improving your recovery posture can silently push a warm site toward hot. Confirm the DR test provisions in writing before any exercise that activates capacity, and align tests with the terms rather than the calendar. Reconcile DR entitlements against the production estate so you are neither exposed nor paying for standby capacity that qualifies as license free. And read the disaster definition and the post disaster run window in your specific contracts, because the bounded period and the narrow definition are where the real obligation sits. For the cost mechanics during an event, see Capacity on Demand and MSU consumption optimization.

Related concepts: Capacity on Demand, sub-capacity vs full capacity, and Monthly License Charge. Where these products live: z/OS licensing. Put it to work: IBM cost optimization.