IBM Mainframe Licensing
IBM mainframe licensing is one of the most complex and expensive aspects of enterprise IT.
The software running on IBM z Systems (z13, z14, z15, z16, etc.) often ends up costing more than the hardware itself. Why? IBM’s Monthly License Charge (MLC) model, based on MSU consumption (Million Service Units of processing), can make your z/OS software bills dwarf your server costs.
The pricing formulas and terms are intricate, leaving many IT asset managers and procurement leaders scratching their heads (and clutching their wallets).
In this guide, written in the voice of an IBM mainframe licensing and negotiation expert, we’ll break down licensing basics, explain the mechanics of sub-capacity pricing, explore how hardware upgrades impact costs, and share proven cost optimization tactics.
We’ll also delve into negotiation strategies to help you push back against IBM and manage those escalating MLC bills.
The goal: arm you with a strategic, skeptical eye toward IBM’s pricing and the levers you can pull to optimize mainframe software spend.
1. Mainframe Licensing Basics
IBM Mainframe Software Licensing Models: IBM offers two primary licensing models for mainframe software – Monthly License Charge (MLC) and One-Time Charge (OTC).
The MLC model is the most common for IBM z/OS and its core subsystems. Under MLC, you pay a recurring monthly fee for software such as z/OS itself, IBM Db2 for z/OS (database), CICS (transaction processing), IMS (database/transaction processing), IBM MQ (messaging), and other products.
These monthly charges are usage-based, measured in MSUs (Million Service Units) – a unit of processing power consumed.
In other words, the more MSUs you use (especially at peak times), the higher your monthly bill.
By contrast, One-Time Charge (OTC) licensing (also known as IPLA licenses in IBM terms) involves paying an upfront fee for a perpetual license, with optional annual support fees.
OTC is rare in modern z Systems environments – most critical IBM mainframe software has moved to MLC or subscription models.
You might encounter OTC for some utility tools or smaller products, but for the “big iron” software that runs your mainframe workloads, expect MLC to dominate costs.
Key Cost Driver:
For MLC software, a single peak in usage can result in a significant increase in cost. IBM typically measures your highest 4-hour rolling average utilization in a month (the peak MSU consumption) for each product and charges based on that peak.
So if one critical workload surges and drives up MSU usage, it can inflate your entire month’s bill.
In essence, more MSUs = more money out of your pocket.
This is why mainframe teams obsess over workload tuning and peak shaving – a little efficiency can save a lot of cash when multiplied by IBM’s pricing.
Checklist: To get a handle on mainframe licensing basics, start with these steps:
- Identify MLC vs. OTC products: Inventory that includes IBM mainframe software in your environment, which is billed monthly (MLC), versus any that were acquired as one-time licenses. This indicates where the recurring costs originate.
- Validate current MSU usage: Gather recent reports of MSU consumption (e.g., IBM’s SCRT reports) to understand your peak MSU levels for each product. Trust, but verify – ensure the usage data IBM is billing matches your expectations.
- Map workloads to cost drivers: Connect the dots between business workloads and the MSU consumption. Identify which applications or logical partitions (LPARs) are causing those peaks. This mapping enables you to target high-cost workloads for optimization.
2. Sub-Capacity Licensing on Mainframe
One saving grace in IBM’s model is sub-capacity licensing. With sub-capacity pricing, IBM charges based on your actual usage peaks rather than the full capacity of your hardware.
In the old days of full-capacity licensing, if you had a gigantic mainframe capable of 1,000 MSUs, you paid as if you used all 1,000 MSUs, even if your workload only needed 300.
Sub-capacity changed that: if you only peak at 300 MSUs, you pay for 300 (not 1000). This approach has become standard for most modern mainframe shops because it prevents the need to pay for idle capacity.
How it works:
IBM requires you to run a utility called the Sub-Capacity Reporting Tool (SCRT) each month. SCRT collects detailed usage data from your system (across all LPARs) and figures out the peak rolling 4-hour average (R4HA) MSU usage for each licensed product.
You submit that SCRT report to IBM, and it forms the basis of your MLC bill. In short, SCRT is your ticket to “pay for what you use”. If you don’t run SCRT or your system isn’t eligible for sub-capacity, IBM will revert to charging as if you ran at full capacity – a costly mistake to avoid.
Pitfalls to watch: Sub-capacity pricing is great, but only if managed correctly. Common issues include:
- Incorrect or late SCRT reporting: If you misconfigure SCRT or fail to submit reports on time, IBM could charge you at full capacity or use default (worst-case) assumptions. Always double-check that SCRT data is accurate every month.
- Poor LPAR management: If you have many LPARs, how you distribute workloads matters. For instance, if two LPARs on the same machine run the same product at different times, IBM will use the one with the highest usage. But if they peak simultaneously on separate machines (without aggregation), you might be paying two high bills. Organizing workloads to avoid overlapping peaks and possibly consolidating LPARs can reduce the combined peak.
- Surprise peak spikes: Even under sub-capacity, a brief surge (e.g., an unplanned batch job or a runaway query) can raise the 4-hour average and balloon your bill. Many organizations have learned the hard way that a single rogue workload can add millions to their annual MLC costs. Proactive monitoring and workload scheduling (running heavy jobs in off-peak hours) are critical to prevent this.
In summary, sub-capacity licensing is essential for cost control on the mainframe, but it requires vigilance and good governance.
Pay attention to the fine print as well: ensure your IBM contract or license agreements explicitly allow sub-capacity pricing for all your products and that you meet IBM’s technical requirements (most modern z Systems do, but prerequisites such as running all z/OS in 64-bit mode are necessary).
Checklist: To fully leverage sub-capacity pricing and avoid pitfalls:
- Validate SCRT reports monthly: Don’t just run the tool – review the output. Make sure the reported peak MSUs align with your internal monitoring. Catch anomalies or errors before IBM’s invoice becomes due.
- Monitor LPAR peaks: Continuously watch the MSU utilization of each LPAR, especially the rolling 4-hour average. Identify if multiple LPARs running the same software could stagger their usage to keep the overall peak lower.
- Confirm sub-capacity terms in contract: Double-check that your IBM agreements include sub-capacity licensing for all eligible products. Ensure you’re not inadvertently in a full-capacity situation due to an overlooked contract clause or unsupported configuration.
3. Hardware Upgrades & Licensing Impacts
Upgrading your mainframe hardware (say, moving from an older IBM z13 to a newer IBM z15 or z16) is usually done for performance, capacity, or reliability benefits.
However, many organizations are surprised to discover that their software bill increases after a hardware upgrade – even if their workload remains unchanged. The reason lies in how IBM rates the capacity of new machines in MSUs.
MSU Ratings Increase with New Generations:
IBM defines an MSU rating for each model and processor speed. Newer mainframes have more powerful CPUs, which can complete more work in the same time – IBM often assigns them higher MSU per core values.
So, if your workload was using, say, 100 MSUs at peak on a z13, that same workload might register as 120 MSUs on a z15 because the machine is faster and can do more work in a shorter time.
In effect, IBM’s pricing metrics “see” more capacity being used, even though you haven’t actually grown the business workload. The result? Higher MLC charges.
To make matters worse, when organizations install a new, faster mainframe, users and applications often consume the newfound headroom (since things run faster, they may do more, or you consolidate more work onto it).
Without controls, a hardware refresh can lead to a double-whammy: a higher MSU rating plus additional usage of capacity, compounding the cost increase.
It’s not uncommon for a mainframe shop to upgrade its hardware and then see a double-digit percentage increase in monthly software fees, which can offset the hardware performance gains in terms of budget impact.
Mitigation strategies:
Don’t let IBM’s revenue automatically increase with your upgrade. You have a few levers to counteract this:
- Workload tuning on new hardware: Leverage the efficiency of the new system by optimizing your applications. If the new machine completes tasks faster, you might be able to shorten batch windows or eliminate bottlenecks, potentially reducing the sustained MSU usage during peak periods. In practice, this is hard to quantify, but every bit of optimization helps keep the peak down.
- Capacity capping: IBM z/OS features such as Defined Capacity and Group Capacity Limits (commonly referred to as soft capping when used strategically) enable you to set an upper MSU limit for an LPAR or a group of LPARs. After an upgrade, you might intentionally cap the system to simulate the previous machine’s capacity. For example, if your old machine peaked at 500 MSUs, you can set a cap so that the new machine doesn’t exceed 500 MSUs without explicit decision. This prevents accidental runaway costs. The downside: if you hit the cap, performance will be throttled. Still, many choose a cap as a safety net while they assess actual needs on the new hardware.
- Negotiate upgrade credits with IBM: IBM knows software cost is a barrier to hardware sales, so they sometimes provide Technology Upgrade Credits or transitional discounts when you move to a new mainframe. Essentially, these are discounts or credits applied to your MLC software charges for a specified period (or a reduced MSU rate) to offset the increased capacity of the new machine. Important: IBM sales representatives won’t always volunteer this information – you must ask for it and push for it during the hardware purchase negotiation. Leverage the fact that IBM wants to sell you that shiny new z16. Insist that part of the deal is a commitment that your software bill won’t skyrocket. This could come in forms like a temporary MSU billing cap, a fixed-price period, or explicit credit dollars that reduce your monthly charges.
In short, when planning a hardware refresh, budget for software impacts and use it as a negotiation opportunity. Go in eyes open: upgrading the mainframe without a plan for software costs is inviting a budget surprise.
4. Cost Optimization Tactics
Controlling IBM mainframe software costs requires active ongoing management.
Beyond the broad strokes of sub-capacity licensing and hardware planning, there are several tactical measures you can implement to trim your Monthly License Charge spend.
Here are some of the most effective cost optimization tactics for IBM Z environments:
- Soft Capping: Soft capping involves setting limits (caps) on the MSU consumption of your systems. Using z/OS features such as Defined Capacity or Group Capacity, you can configure a maximum MSU usage for specific LPARs or workload groups. When the defined cap is reached, the system will constrain CPU usage to prevent additional MSUs from being consumed (thereby holding the line on cost). Soft capping is a delicate balancing act: you’re intentionally putting a ceiling on performance to save money. The key is to apply caps where you have non-critical or delay-tolerant workloads, or to cap just above your typical peak so that only unusual spikes get throttled. When done correctly, soft capping can prevent those budget-busting peaks while having a minimal impact on users. It’s one of the primary tools in the arsenal of capacity planners trying to rein in costs.
- Aggregation of LPARs: The arrangement and aggregation of workloads can significantly influence cost efficiency. IBM bills sub-capacity MLC by product across each machine (CPC). If you have the same product running on multiple separate mainframes, each machine will have its own peak. But if you consolidate workloads onto fewer machines or clusters of LPARs, you can often reduce the number of independent peaks. The aim is to combine usage such that one lower peak replaces multiple higher ones. For example, if you run two separate LPARs of CICS on two different machines, each might peak at 100 MSUs (paying for 100 twice). If you can run them on the same machine (or the same LPAR group under something like Country Multiplex Pricing), you might end up with a single peak of 150 instead of two peaks of 100 – saving you 50 MSUs worth of charges. This is a simplistic example, but the idea is to explore whether you can consolidate LPARs or use IBM pricing structures that aggregate usage across systems. Fewer, larger systems with well-managed workload distribution can be more cost-effective than many small isolated ones (plus it simplifies SCRT reporting).
- Workload Management (WLM) Tuning: IBM’s Workload Manager (WLM) on z/OS is a powerful tool for prioritizing and controlling how different jobs utilize resources. By tuning WLM policies, you ensure that high-priority work gets done first, and less critical work waits its turn if the system is under strain. From a cost perspective, a good WLM setup can prevent lower-priority tasks from running amok during peak periods. For instance, you might have background report generation or test environments that consume CPU – WLM can be configured to scale back on those when more important online transactions are occurring. The goal is to avoid a scenario where non-essential work contributes to your monthly peak MSU usage. Align your WLM goals with cost goals: let it throttle or delay discretionary workloads when needed to flatten the peak. Additionally, workload scheduling (a part of operational tuning) goes hand-in-hand with WLM – e.g., run heavy batch jobs at night or weekends when online workload is low, so they don’t overlap and spike the cumulative usage.
- Country Multiplex Pricing (CMP): IBM’s Country Multiplex Pricing is an offering that enables clients with multiple mainframes in a single country to consolidate their MSU usage. Under CMP, IBM effectively treats a group of machines as one “virtual” machine for billing, taking a combined peak across all of them. This can be beneficial if your systems’ peaks occur at different times. For example, if one mainframe peaks in the morning and another in the evening, you would separately pay for both peaks. However, under CMP, IBM would charge you for something closer to the overall peak of the group, which might be lower than the sum of the two peaks. Note: IBM typically requires that you switch to a specific pricing metric (such as CMP replacing your standard AWLC or Tailored Fit metrics), and sometimes there’s a baseline or uplift in price to use CMP. It’s not designed to immediately slash your bill, but rather to provide flexibility as you add capacity. In a best-case scenario, CMP can reduce costs for distributed workloads and make your billing more predictable. In the worst-case scenario, if not managed properly, you may pay a premium for the pooling benefit. So evaluate it carefully. For organizations with many mainframes, CMP is certainly worth exploring – it can simplify billing and potentially avoid “each box pays max” issues.
Beyond these, also consider third-party cost management tools (several vendors offer software that analyzes your SMF data in depth to find inefficiencies or recommend optimal capping settings) and regularly review IBM’s latest pricing programs (like any new targeted discounts for specific workloads).
The main idea is to create a culture of continuous optimization – treat MLC like a utility bill you can influence by being energy-efficient in IT terms.
Checklist: Implementing mainframe cost optimization tactics should involve:
- Soft caps configured: Set up Defined Capacity or Group Capacity limits where appropriate to curb unnecessary peaks. Regularly review and adjust the cap values to strike a balance between cost and performance.
- LPAR aggregation evaluation: Review your LPAR and mainframe footprint to identify opportunities for consolidating workloads or utilizing pricing constructs (such as CMP) to aggregate usage for improved pricing efficiency.
- CMP eligibility explored: If you operate multiple mainframes in the same country, discuss Country Multiplex Pricing with IBM. Model the costs under CMP versus the status quo to determine if it benefits your situation.
- WLM tuning applied: Ensure your Workload Manager policies align with cost optimization – critical workloads get priority, and less critical work can be held back during potential peak times. Continuously tune and monitor to keep your resource usage efficient.
5. Negotiation Strategies for Mainframe Licensing
Even after optimizing technically, significant savings on IBM mainframe costs often result from negotiations at the table. IBM’s pricing and discounting for mainframe software can be opaque and highly customer-specific.
As a procurement or IT asset manager, you need to approach IBM deals strategically and skeptically – assume there’s always a better deal hidden behind the list price or initial offer.
Here are some battle-tested negotiation insights for IBM mainframe licensing:
Leverage IBM’s willingness to deal: IBM wants to keep you on the platform and sell you more – whether that’s a hardware upgrade, a multi-year contract, or new products. Use this to your advantage. For example, when you’re about to buy a new mainframe or renew a large agreement, ask for Technology Upgrade Credits.
These are essentially discounts or credits IBM provides to offset software cost increases associated with hardware upgrades (as mentioned earlier). Make it a condition of the hardware sale – “We’ll invest in that new z16, but we need an X% reduction in MLC charges for the next 2 years to make the TCO work.” You’d be surprised: IBM often has internal programs to fund such credits, especially at quarter-end or year-end deals, but if you don’t ask, you likely won’t get them.
Similarly, inquire about MSU reduction incentives. IBM sometimes runs programs or one-off arrangements where, if a customer can demonstrably reduce their MSU usage (through, say, application optimization or moving workload off the mainframe), IBM will adjust the billing or provide a credit so they’re not punishing you for using less. Why would IBM do that?
In some cases, IBM would rather give a slight break than see you aggressively move workloads to the cloud or another platform. It’s all in how you position it: make IBM feel like a partner in efficiency rather than an adversary (even if you remain healthily skeptical behind the scenes).
Buyer’s negotiation tactics:
- Always request discounts/credits during upgrades and renewals: Never accept the first quote. IBM’s initial MLC pricing often assumes no discount or, at most, a standard volume discount. There is usually room for more, especially if you are a significant mainframe client. Ask explicitly for concessions whenever you’re making a big purchase or signing a multi-year deal. This includes caps on price increases, extra capacity at no charge, or temporary freezes on billing while you implement cost-saving measures.
- Insist on contractual caps or fixed pricing terms: One way to control risk is to bake protections into your IBM contract. For instance, negotiate a clause that your MLC rates will not increase by more than a certain percentage year-over-year, or that if your MSU usage goes down, your cost will ratchet down correspondingly (not just stay at a high-water mark). IBM contracts can be modified – don’t assume you have to take the boilerplate. You might push for a multi-year fixed price for a bundle of MSUs (similar to a tailored deal) if that provides budget certainty, or at least an extended grace period after hardware upgrades, during which software charges won’t increase.
- Benchmark against peers: Knowledge is power. Try to find out what similar organizations (in your industry or of your mainframe size) are paying or what discounts they have achieved. IBM’s pricing is highly discretionary; two companies of equal size might pay very different rates per MSU depending on their negotiation prowess. Use user groups, consultants, or market research to get a sense of the “street price.” If you can go to IBM and say, “Enterprise X got a 30% lower rate – we know the ballpark figures,” it changes the tone of the negotiation. IBM will recognize that you’ve done your homework and may match those discounts to retain your business.
- Escalate and bundle for better terms: If your initial negotiations aren’t yielding much, don’t hesitate to escalate to higher levels within IBM. Sometimes sales reps have limited authority, but their managers or executives overseeing strategic accounts can approve special deals (especially if you hint at considering moving off the mainframe or drastically cutting capacity – even if just a negotiation bluff). Additionally, consider bundling multiple items into a single negotiation, including hardware, software, services, and other IBM products. A larger deal gives you more leverage to ask for global concessions. For example, negotiating an Enterprise License Agreement (ELA) that covers a suite of IBM software (mainframe and maybe some distributed) in one go can open up more flexible pricing than doing it piecemeal.
- Prepare a strong business case: Come to negotiations armed with data and options. Show IBM your SCRT reports and what your current cost trajectory is, then demonstrate the steps you’re willing to take to reduce cost (e.g., “We are actively optimizing our code to reduce MSUs by 10%” or “We are evaluating moving this application off the mainframe”). If IBM senses that you have a plan to control or cut usage, they may offer a deal to keep those workloads on IBM Z. The worst position is to appear captive and complacent; the best is to show you’re actively managing costs and have alternatives. That creates pressure on IBM to cooperate or risk losing business.
Finally, maintain a healthy skepticism. IBM’s sales team is well-trained to maximize revenue. Contracts may include clauses that allow IBM to reprice if you make certain changes or obscure the calculation of billing.
Read the fine print and don’t be afraid to seek expert help (some consultants specialize in IBM contract negotiations).
Every percentage point off your MSU rate or every constraint you can add to limit charges can translate to millions in savings over a few years for a large mainframe shop. It’s worth the battle.
Related articles
- IBM Tailored Fit Pricing for Z: A Game Changer or Cost Trap?
- IBM Sub-Capacity Licensing on Mainframe vs Distributed: What’s the Difference?
- Leveraging IBM Specialty Processors (zIIP, zAAP) to Reduce Licensing Costs
- IBM Mainframe Licensing Negotiation: Checklist for Success
- Reducing IBM MLC Costs: Mainframe Monthly License Charge Optimization
6. FAQs
Q: Why did our IBM mainframe software bill increase after a hardware upgrade?
A: Newer hardware (like moving from a z13 to z15/z16) often carries higher MSU ratings per core, so software charges increase even with the same workload. Unless you negotiate credits or apply capping, IBM benefits from the upgrade while your bill escalates.
Q: How can we negotiate better MLC pricing with IBM?
A: Start with hard data (SCRT reports) to show actual usage and trends. Request MSU reduction incentives and insist on Technology Upgrade Credits during hardware refresh negotiations. Don’t settle with the sales rep’s first offer – escalate if necessary – and use peer benchmarks to negotiate fair discounts.
Q: Can sub-capacity pricing really save significant costs?
A: Yes, sub-capacity billing means you’re charged on usage peaks, not full machine capacity. With optimized SCRT reporting and smart LPAR management, companies often cut 10–20% of unnecessary MLC spend. If you mismanage reporting or let workloads spike unchecked, however, those savings vanish.
Q: What tools or techniques help optimize mainframe costs?
A: Key tools include IBM’s own SCRT (for tracking usage) and features like soft capping and Workload Manager (WLM) to control peaks. There are also third-party mainframe cost optimization tools that analyze usage patterns. Enterprises that consistently monitor and adjust capacity (and use these tools) often save millions of dollars annually on MLC fees.
Q: Are there alternatives to IBM’s traditional MSU-based pricing model?
A: IBM isn’t abandoning MSU-based billing anytime soon, but you can negotiate custom arrangements. Some large customers secure tailored pricing bands, caps on MSU charges, or regional pooling (such as CMP) to reduce costs. IBM’s newer programs (e.g., multi-year commitment deals or “Tailored Fit Pricing”) may offer flat-rate or subscription-like models, but these typically require a big commitment. For strategic accounts, IBM is sometimes willing to craft a unique deal – especially tied to hardware refresh cycles or long-term agreements – so it’s worth exploring if your mainframe environment is sizable.
Read about our IBM Licensing Advisory Services
