① Guides · Broadcom (CA) MCL
Broadcom (CA) Mainframe Consumption Licensing prices everything relative to one number: the consumption baseline. Set it on an unoptimized estate and you commit to paying for avoidable MSU across the entire term. The baseline is not a detail in an MCL deal. It is the deal.
Everything prices off one number.
Under Broadcom (CA) Mainframe Consumption Licensing, consumption is typically measured as total hourly MSU utilization across the production LPARs running z/OS, with a standard annual true up. Broadcom positions the model as removing the need for manual capping and resource gymnastics: you commit to a baseline level of consumption, usage above it draws overage, and usage below it can commonly be rolled over to the next period, like rollover minutes. For customers licensing IBM development and test container solutions, the model can exclude dev and test utilization from the measured consumption.
That structure is reasonable on its face, and it can be genuinely better than the old capping treadmill. But notice where the leverage sits. Overage is priced against the baseline. Rollover is measured against the baseline. Your annual commitment is the baseline. A baseline set on an inflated consumption history follows you for the entire term, and Broadcom derives that history from your own reports. The whole negotiation collapses into one question: what number do you commit to, and was the estate optimized before you committed?
The baseline is derived from consumption, so consumption is what you fix first. Profile the R4HA peak, move discretionary work out of the window, and offload what qualifies to zIIP engines. Every avoidable MSU you remove before the baseline is fixed is an MSU you do not pay for across the whole term.
Broadcom builds the baseline from your SCRT reports. Validate that data independently before it becomes the reference point. Anomalous months, one off projects, and migration spikes can all inflate the trailing picture, and a baseline anchored to a non representative period is a baseline anchored too high.
Confirm and document the dev and test exclusion in writing. Development and test workload can be a meaningful share of total MSU, and there is no reason to commit baseline to consumption the model is willing to exclude. Get the definition and the mechanism specified, not implied.
A low rate against a high baseline still overpays. Set the committed baseline to optimized consumption, negotiate the growth ramp so it reflects real forecast rather than vendor assumption, and pin the overage rate and rollover terms. These move together; concede the baseline to win the rate and you have lost the deal that matters.
Build in a true down path so a baseline that turns out too high can be corrected, cap any uplift across the term, and define what happens to the baseline at renewal so the next cycle does not start from an inflated commitment. The model's flexibility is real only to the extent the contract spells it out.
Why the order matters.
Consider two estates with identical real demand. One commits to a baseline first and optimizes after; the other optimizes first and commits to the lower number. Both reduce avoidable consumption by the same amount. Only the second one pays the lower bill, because under MCL the baseline is the commitment, and a commitment made before optimization captures the waste for the term. The savings the first estate generates after signing accrue to the gap between its consumption and its baseline, not to its wallet, until the next renewal lets it reset, if the contract even allows that reset.
The baseline checklist
Consumption is typically measured as total hourly MSU utilization across the production z/OS LPARs, and the baseline is the committed consumption level your pricing is built around. Usage above it draws overage; usage below it can commonly roll over to the next true up. Because everything prices relative to the baseline, the baseline number is the negotiation.
The baseline is derived from your consumption history, and an estate that has never optimized its peaks carries avoidable MSU. Commit to a baseline built on that inflated number and you pay against it for the whole term, even after you later reduce consumption. Optimize first, then commit, and the savings compound for the life of the agreement.
Broadcom has indicated that, for customers licensing IBM development and test container solutions, MCL can exclude dev and test utilization from measured consumption. That exclusion is worth confirming and pinning down in writing, because dev and test can be a meaningful share of total MSU and there is no reason to commit baseline to it.
Rollover lets utilization below the baseline carry into the next true up period, like rollover minutes, which softens the penalty for a conservative baseline and gives room for uneven growth. It is useful, but it is not a substitute for getting the baseline right. A baseline set too high still costs more than a correct one even with generous rollover.
Audit notice or renewal under 18 months out? We mobilize within 48 hours.
Get expert help →