① Explainer · Licensing concept
Broadcom (CA) prices the whole mainframe portfolio on one MSU baseline, smooths your spikes, and lets unused capacity roll over. It also asks you to commit a number up front. That number is the entire negotiation. Here is how the model works, with the math.
The old model billed every product on its own peak. MCL bills the portfolio on one pooled baseline. The savings, and the risk, both live in where you set that baseline.
Broadcom Mainframe Consumption Licensing (MCL) is the consumption based licensing model Broadcom (CA) offers across its mainframe software portfolio. Rather than pricing each product separately on the peak MSU of the LPARs where it runs, MCL establishes a single annual consumption baseline, measured in MSU, that covers the licensed portfolio as a whole. You draw against that baseline as workload runs, and consumption above it is billed under a pricing plan fixed at the start of the term. A true-up reconciles actual usage against the baseline.
Two features change the buyer's position. First, a rollover mechanic commonly lets unused MSU carry from one true-up period into the next, which softens the penalty for seasonality. Second, qualifying IBM development and test container usage is commonly excluded from the consumption that counts, so your test estate does not inflate the production baseline. The catch is the commitment: you are agreeing a number now against future workload. Set it on validated R4HA and SCRT history, never on a vendor forecast.
A simplified estate running four CA products with seasonal peaks. The traditional model bills each product on its own annual peak MSU. MCL bills the pooled portfolio against a single negotiated baseline. The illustrative rates below are for mechanism only, not a price quote.
| Product | Peak MSU (its worst month) | Average MSU drawn | Billed under traditional model |
|---|---|---|---|
| CA 7 (scheduler) | 900 | 620 | on 900 |
| CA View / Deliver | 820 | 540 | on 820 |
| CA SYSVIEW | 760 | 510 | on 760 |
| CA Datacom | 880 | 600 | on 880 |
| Sum billed | 3,360 | 2,270 | 3,360 MSU |
Under the traditional model you pay on 3,360 MSU, the sum of four peaks that almost never occur in the same window. Under MCL, the four products draw against one pooled baseline. Because the peaks do not align, a baseline set near pooled average plus headroom, say 2,600 MSU, can cover real demand while billing roughly 23% below the stacked peak total. The savings is the gap between the sum of peaks and the pooled baseline. The risk is setting the baseline above true pooled need.
MCL bites when the baseline is negotiated off the vendor's growth forecast rather than your measured history, when portfolio breadth you do not use is bundled into the commitment, or when the rollover and true-up terms are vague enough to let a true-down become impossible. A consumption model only beats peak pricing if the baseline sits below the sum of your product peaks and tracks your real pooled demand. The decision table below is how to read whether MCL fits your estate.
| Your situation | MCL signal | The buyer lever |
|---|---|---|
| Seasonal or volatile MSU | Favorable | Pooling and rollover smooth the spikes you were paying full price for |
| Flat, predictable load | Neutral to negative | Little to smooth; demand a baseline at or below current effective spend |
| Broad portfolio, many products | Favorable | Pooling across non aligned peaks is where the gap appears |
| Few products, one big peak driver | Cautious | One product can define the baseline; consider keeping it on its own metric |
| Declining or modernizing estate | Cautious | Insist on true-down rights; a fixed baseline traps a shrinking estate |
| Heavy dev and test footprint | Favorable | Confirm the dev and test exclusion in writing and how it is reported |
MCL terms, rollover behavior, and the dev and test exclusion are Broadcom constructs and vary by contract. Patterns described here are commonly observed; your outcome depends on your portfolio, your consumption history, and the baseline you negotiate.
MCL is the consumption answer to the same problem that drives the rolling four hour average: spiky workload billed at peak. It is the Broadcom (CA) counterpart to IBM Tailored Fit Pricing, and the baseline is set from the same SCRT data. Before you sign one, read how the same dev and test work is priced under container based dev and test licensing, and how raw machine ratings feed cost in model capacity ratings. If a Broadcom renewal or metric transition is in front of you, the baseline is the leverage point, and that is the work on mainframe license negotiation.
Audit notice or renewal under 18 months out? We mobilize within 48 hours. Broadcom proposing an MCL baseline? Have it validated against your own SCRT history before you commit the number.
MCL is Broadcom's consumption based licensing model for the CA mainframe software portfolio. Instead of pricing each product on its own peak MSU, MCL sets a single annual consumption baseline in MSU across the licensed portfolio. You draw against that baseline as you run workload, and usage beyond it is billed under a pricing plan agreed at the start of the term, with a true-up reconciling actual consumption.
Traditional CA licensing prices each product on the peak MSU of the LPARs where it runs, so a spike in one product drives that product's cost. MCL pools consumption across the portfolio against one baseline, smooths seasonal spikes, and commonly adds a rollover feature so unused MSU can carry from one true-up period to the next. The trade is that you commit to a baseline up front, as the worked comparison above shows.
Broadcom has commonly excluded qualifying IBM development and test container utilization from MCL consumption, on the basis that robust dev and test systems should not penalize the production baseline. The exact exclusion depends on your contract terms and how your dev and test environments are configured and reported, so confirm it in writing.
No. MCL helps estates with volatile or seasonal consumption and a portfolio wide spread of products. It can cost more if your baseline is set too high, if your consumption is flat and predictable, or if you are paying for portfolio breadth you do not use. The baseline number is the negotiation. Set it against validated SCRT history, not the vendor's forecast, and insist on true-down rights if your estate is shrinking.