① Explainer · Licensing concept
Most estates pay full production rates on MSU that is only running test jobs. It does not have to be that way. Container Pricing, zD&T, and vendor dev and test discounts all exist to pull non production work off the production bill. Here is how each works, and what it saves.
Test workload counted as production is the most overpaid line in many mainframe budgets. There are three ways to separate it, and each lands the saving differently.
Development and test workload can be licensed several ways. Left alone, it runs inside the production LPARs and counts toward the same rolling four hour average as the live business, so you pay production rates on jobs that exist only to compile and test code. The three mechanisms that fix this are IBM Container Pricing, which prices a defined dev and test container separately even when it runs collocated on the production machine; IBM Z Development and Test Environment (zD&T), which moves dev and test off the mainframe onto x86 entirely; and vendor dev and test discounts, where ISVs price non production usage below production or exclude it from a consumption baseline.
The choice is structural. Container Pricing keeps the work on the mainframe but rings it off for separate metering. zD&T removes it from the machine. Discounts keep it where it is but reprice it. Each suits a different estate, and the saving depends on how much of your billed MSU is actually non production. The worked example below separates a typical estate to show the gap.
An estate billing 1,000 MSU at the production peak, of which 280 MSU is development and test work running in the same LPARs. We separate it three ways and read the billed production MSU under each. Rates are illustrative of the mechanism, not a quote.
| Approach | Dev/test treatment | Billed production MSU | Dev/test cost basis |
|---|---|---|---|
| Do nothing | Counts in production peak | 1,000 | production rate |
| Container Pricing | Metered as a separate container | 720 | container terms |
| zD&T on x86 | Removed from the mainframe | 720 | x86 subscription |
| Vendor dev/test discount | Repriced below production | 720 | discounted rate |
Every separation drops the billed production MSU from 1,000 to 720, because the 280 MSU of test work stops counting at the production rate. What differs is where the dev and test cost then lands: a separately metered container, an x86 subscription, or a discounted line. The headline production saving is the same 28%; the right mechanism depends on whether you can move the work off the machine and how your vendor reports non production usage.
The separation only pays if you can prove which MSU is dev and test and if the contract recognizes the carve out. The common traps: a discount agreed verbally but never written into the agreement, a container defined so narrowly that real test work falls outside it, or a zD&T move that ignores the third party products the test estate also needs licensed. The decision table maps each approach to the estate it fits.
| If your estate is | Best fit | Watch for |
|---|---|---|
| Heavy test, must stay on the mainframe | Container Pricing | Container scope; reporting that proves the boundary |
| Test work that can run off platform | zD&T on x86 | Third party products the test estate still needs |
| On a consumption model already | Dev/test exclusion in the baseline | Get the exclusion in writing, not on a call |
| Spread across many ISV products | Per vendor dev/test discount | Each ISV negotiated separately; none is automatic |
| Mixed prod and test in one LPAR | Container Pricing or LPAR split | Without separation there is nothing to discount |
Container Pricing, zD&T, and vendor dev and test discount terms are vendor constructs that change over time and vary by contract. Treat the figures and routes here as the mechanism, not a guarantee; verify the current terms and reporting requirements for your products before you rely on a carve out.
Dev and test separation works on the same MSU and R4HA that drive production cost, and Container Pricing is closely related to collocated application pricing (zCAP), which applies the same collocation idea to new production applications. On the third party side, Broadcom's Mainframe Consumption Licensing commonly excludes qualifying dev and test from its baseline. Identifying the non production MSU, proving the boundary, and writing the carve out into the contract is the work on mainframe cost optimization.
Audit notice or renewal under 18 months out? We mobilize within 48 hours. Paying production rates on test MSU? We can separate it before the next renewal locks it in.
Dev and test workloads can be licensed in several ways: priced inside the production MSU like any other work, carved into an IBM Container Pricing solution that prices the dev and test container separately, or moved off the mainframe entirely onto IBM Z Development and Test Environment (zD&T) running on x86. Vendors also commonly offer dev and test discounts that price non production usage below production rates.
Container Pricing for IBM Z lets a defined workload, such as application development and test, be priced as a separately measured container even when it runs collocated with production on the same machine. The dev and test container is metered and priced on its own terms, so the work does not inflate the production MSU that drives the rest of the software bill.
IBM Z Development and Test Environment (zD&T) emulates a z/OS environment on low cost x86 hardware. It moves development and test off the production mainframe entirely, so that workload consumes no production MSU at all. It is licensed on its own subscription terms rather than as mainframe MLC, which suits teams that can run dev and test away from the live machine.
Commonly, yes. Many mainframe ISVs price non production usage below production, and some consumption models exclude qualifying dev and test from the metered baseline entirely. The discount is rarely automatic. It usually has to be requested, defined in the contract, and supported by a reporting method that proves which MSU is dev and test versus production.