① Licensing · Sysplex Aggregation
Two machines priced separately each pay the expensive low end of the tier schedule. Joined into a qualified sysplex and priced as one pool, the same MSU climbs into the cheaper bands once. Aggregation is one of the few pricing mechanics on the frame that reliably moves the bill down, and a surprising number of estates that qualify never claim it.
One pool, priced once.
Parallel Sysplex aggregation is the pricing treatment under which the MSU for a sub-capacity eligible product running across multiple machines in a qualified Parallel Sysplex is summed and priced as a single pool, with the base charge for the product paid only once, rather than each machine being treated as a standalone environment with its own charge.
The mechanic matters because Monthly License Charge schedules are graduated: the per MSU rate falls as volume rises. Pricing each machine on its own pays the costly low tiers again and again. Aggregating the MSU into one larger pool means the combined volume passes through the cheaper high tiers, so the same total work costs less priced together than priced apart. This is the same family of mechanics as usage pools and aggregation across sysplexes, read at the single sysplex level.
Standalone versus aggregated.
Take one MLC product running on two machines, each carrying a 150 MSU peak for that product. Priced standalone, each machine pays through the same expensive opening tiers. Priced as one aggregated 300 MSU pool, the combined volume reaches the cheaper bands and the base charge is paid once, not twice. Using an illustrative graduated schedule:
| Tier band (MSU) | Illustrative rate per MSU | Standalone (2 × 150) | Aggregated (1 × 300) |
|---|---|---|---|
| 1 to 100 | $45 | $9,000 | $4,500 |
| 101 to 200 | $32 | $3,200 | $3,200 |
| 201 to 300 | $24 | n/a | $2,400 |
| Monthly charge, 300 MSU total | $12,200 | $10,100 |
Illustrative rates and bands for arithmetic only. Real MLC schedules are product specific and confidential to your contract.
Same product, same 300 MSU of work, two machines. Standalone pricing pays the costly 1 to 100 band twice, once per machine. Aggregated pricing pays it once and lets the rest of the volume fall into the cheaper bands, taking roughly $2,100 a month off this single product. Now read that across a full MLC stack of a dozen products and the annual difference between claiming aggregation and not claiming it is large. The work to capture it is mostly proving qualification, not changing anything about how the workload runs.
What unlocks the pool.
Aggregation is not automatic. IBM's Parallel Sysplex pricing terms set qualifying conditions, and the saving applies only once the sysplex meets them and IBM is notified. The tests commonly observed are these.
| Test | What it commonly requires |
|---|---|
| Physical coupling | Machines connected through a common coupling facility |
| Common time reference | A shared external time source across the sysplex |
| Workload share | Sysplex images carry a meaningful share of each machine's workload |
| Enablement function | At least one common sysplex function using the coupling facility active |
| Notification | IBM informed that the sysplex qualifies before pricing applies |
The precise thresholds live in IBM's current Parallel Sysplex pricing terms and are verified per estate before relying on the saving.
Two patterns recur in the field. First, estates that technically qualify but never notified IBM, so they are paying standalone pricing on a sysplex that should aggregate. Second, estates that qualified once, then a configuration change quietly broke a condition and aggregation lapsed without anyone noticing the bill move. Both are recoverable, and both are exactly the kind of thing a buyer side review surfaces, because the saving is sitting in a contract clause nobody re tested. For the related question of when a workload is better off standalone, see sysplex versus standalone pricing.
How to optimize it.
Levers on sysplex aggregation
Across 500+ engagements and $180M+ of negotiated mainframe spend, aggregation is one of the most consistent sources of recovered cost we see, precisely because it depends on a contract treatment that estates set up once and rarely revisit. The MSU does not change. The pricing of it does, and the gap between aggregated and standalone on a qualifying estate is money that is already yours to claim.
The pricing treatment under which the MSU for a sub-capacity eligible product running across multiple machines in a qualified Parallel Sysplex is summed and priced as one pool, with the base charge paid only once, rather than each machine being priced as a standalone environment.
Because MLC schedules are graduated, the per MSU rate falls as volume rises. Pricing each machine standalone pays the expensive low tiers repeatedly. Aggregating combines the MSU into one larger pool that climbs into the cheaper high tiers once, so the same total MSU costs less priced together than priced apart.
Commonly the machines must connect through a coupling facility and a common time reference, the sysplex images must carry a meaningful share of each machine's workload, at least one common sysplex enablement function must be active, and IBM must be notified. The precise tests live in IBM's Parallel Sysplex pricing terms and are verified per estate.
Rarely on the charge, but the qualifying conditions carry obligations. Maintaining the workload balance and coupling configuration has operational implications, and a change that breaks qualification can revert products to standalone pricing. The saving is real but conditional, so the conditions belong in the cost model.
Audit notice or renewal under 18 months out? We mobilize within 48 hours.
Get expert help →