Overview
IBM Z mainframes continue to run mission-critical applications in 2025, but the cost of IBM’s system software remains a top concern for CIOs. Mainframe software licensing is notoriously complex and can account for a significant portion of IT spending, often one-third or more of overall mainframe costs. Managing these costs requires a clear understanding of IBM’s licensing models and careful planning to avoid compliance pitfalls.
This advisory provides an unbiased look at IBM mainframe (Z Systems) software licensing – from the traditional Monthly License Charge (MLC) model to IBM’s newer Tailored Fit Pricing (TFP) options – and offers guidance on optimizing costs without violating license terms.
The goal is to help CIOs make informed decisions and control mainframe software expenses, leveraging independent IBM licensing expertise (e.g., Redress Compliance) where appropriate for contract and compliance support.
The Traditional MLC Model on IBM Z
Monthly License Charge (MLC) is the longstanding model under which IBM licenses many of its core mainframe software products. MLC applies to the operating system (z/OS) and major subsystems, such as IBM Db2 (database), CICS (transaction monitor), IMS (database and transaction server), and IBM MQ (messaging middleware), on z/OS.
Under MLC, customers pay a recurring monthly fee for these software licenses. Charges are usage-based and measured in terms of processing capacity used, most commonly in MSUs (Million Service Units), a unit of mainframe processing power.
Rather than a simple per-processor fee, IBM uses sophisticated metrics to determine monthly charges based on the actual horsepower your workloads consume.
How MLC Pricing Works:
In an MLC model, IBM measures the peak usage of each eligible software product within the month. For capacity-based pricing, IBM historically relies on the Rolling 4-Hour Average (R4HA) metric, which is essentially the average utilization of the system over the highest sustained 4-hour window in a month. In practice, IBM’s tools sample CPU usage frequently and compute a rolling average. The highest such 4-hour average for each product determines the billable MSU consumption.
For example, if your Db2 workload peaks at an R4HA of 500 MSUs one afternoon, and that is the highest for the month, your Db2 license charges are based on 500 MSUs for that month. IBM offers tiered pricing and discounts that apply as MSU volumes increase. However, the key point is that a single spike in usage can significantly increase the monthly cost.
Full Capacity vs. Sub-Capacity:
Originally, mainframe software was charged at full machine capacity, meaning you paid for the entire MSU rating of your mainframe, regardless of actual usage. To avoid punishing customers for unused headroom, IBM introduced sub-capacity licensing, which allows billing based on the peak utilized capacity rather than the installed capacity.
Virtually all modern z/OS installations operate under sub-capacity MLC pricing, as it can save significant costs by charging only for the capacity used at peak times. Full-capacity licensing may still apply in certain scenarios (e.g., if the system does not meet IBM’s requirements for sub-capacity). Still, most clients ensure they qualify for sub-capacity to avoid paying for idle capacity.
Sub-Capacity Licensing on IBM Z
Under sub-capacity licensing, organizations report their mainframe usage to IBM every month using the IBM Sub-Capacity Reporting Tool (SCRT). SCRT gathers detailed utilization data for all LPARs (logical partitions) and eligible products, calculates the R4HA for each product, and produces a sub-capacity report.
This report is submitted to IBM and serves as the basis for MLC billing. Compliance with SCRT reporting is critical – IBM requires accurate monthly (or at least quarterly) reports; failing to run SCRT or misreporting usage can result in IBM reverting to full-capacity charges or other compliance penalties. In essence, SCRT is what makes “pay for what you use” possible on the mainframe.
The rolling 4-hour average (R4HA) mechanism means that the highest sustained workload levels drive the cost. Many organizations have responded by implementing careful capacity management, such as tuning applications, scheduling batch jobs during off-peak hours, and using capping tools to limit peak CPU usage.
By capping peak usage, you can control costs, but the trade-off is potential performance constraints. For instance, a bank might cap its online transaction processing LPAR to a certain MSU limit to avoid a budget overrun, even if the mainframe hardware could handle more throughput.
This underscores a classic challenge with traditional MLC: IT teams often “architect around price,” sometimes holding back on utilizing available capacity due to cost concerns.
IBM’s MLC pricing also spawned various special programs to ameliorate specific use cases. Examples include IBM’s Container Pricing for development and test environments, as well as Mobile Workload Pricing, which offered discounts for specific new workloads.
These programs, layered on top of MLC, aimed to reduce costs in growth areas, such as mobile transactions or development and testing capacity, without requiring a full pricing model change. Still, managing all these variations added to the complexity.
By the late 2010s, it was clear that while sub-capacity MLC saved money versus full-capacity, the complexity and unpredictability of monthly bills remained pain points. This led IBM to propose a new approach under the banner of Tailored Fit Pricing.
Tailored Fit Pricing: Modern Licensing Options
In 2019, IBM introduced Tailored Fit Pricing (TFP) for IBM Z, a new licensing program intended to simplify mainframe software pricing and bring more predictability. TFP represents a significant shift from the traditional R4HA-based MLC model.
Rather than charging each month’s bill based on the peak in that month, TFP offers pricing arrangements that behave more like cloud subscriptions or all-you-can-eat models. The aim is to let customers use their mainframes more freely, “leverage the strengths of the platform as opposed to architecting workloads around price,” as one IBM executive put it.
Under TFP, IBM offers two primary models: the Enterprise Consumption Solution and the Enterprise Capacity Solution. Both models cover a broad set of IBM Z software (the same products that would be under MLC) and can coexist with special offerings for dev/test or new applications. Here’s how they work:
Enterprise Consumption Model
The Enterprise Consumption Solution is a usage-based, pay-as-you-go model for mainframe software. Instead of worrying about monthly peaks, customers pay for the total MSU consumption over time.
IBM typically measures the aggregate MSU usage hourly or monthly and charges according to the total amount of CPU consumed (for example, annually). In practical terms, IBM works with the client to set a yearly consumption baseline, often based on the previous 12 months of usage, which is then divided into a predictable monthly rate.
This baseline acts like a subscription for a certain amount of MSU usage per year, and charges will scale with actual usage.
Key benefits:
This model is well-suited for organizations with highly variable or seasonal workloads. If your mainframe usage fluctuates up and down (end-of-quarter processing, holiday spikes, etc.), consumption pricing helps smooth out the costs. Short-term spikes no longer cause a full month’s bill to jump the way they would under R4HA; instead, they contribute to the cumulative usage.
There is much less need for artificial capping – you can let workloads run when needed, confident that you’re paying for the actual CPU used across the year, not for the worst-case peak.
Many CIOs appreciate the predictability and transparency of this model: you generally know your rate per MSU and can forecast costs based on projected workload volumes. If you consume less, you pay less; if you consume more, you pay more – analogous to a utility bill.
However, IBM typically builds in some financial guardrails: for example, if usage greatly exceeds the anticipated baseline, there may be provisions for overage charges or an opportunity to adjust the contract.
The goal for both IBM and the customer is to avoid big surprises by using historical data to set a reasonable baseline. Enterprise Consumption TFP essentially brings a cloud-like elasticity to mainframe software billing.
Enterprise Capacity Model
The Enterprise Capacity Solution is a full-capacity, fixed-price model that offers maximum simplicity. Instead of tying cost to the amount of CPU used, this model ties cost to the available CPU power.
A customer agrees on a defined physical capacity for their mainframe environment (for example, a certain number of MSUs corresponding to the size of their machines or LPAR configuration), and IBM charges a fixed monthly fee based on that capacity.
In effect, you are pre-paying for the entire capacity of your mainframe environment, and in return, you can run unlimited workloads on that capacity with no incremental software cost. All the IBM Z software in the agreement is fully licensed for the environment, so you don’t need to track usage for cost purposes – no more R4HA concerns.
Key benefits: Enterprise Capacity provides cost certainty and operational freedom. It’s analogous to an all-inclusive plan: the monthly bill is the same, regardless, making it easy to budget. This is particularly attractive for organizations with relatively steady workloads or those who want to aggressively expand mainframe usage without continual renegotiation. If you have significant idle capacity today, this model encourages you to put it to work.
Since you’re paying for it regardless, any new workload is essentially free of software charges. It also simplifies compliance: as long as you stay within the agreed-upon capacity and meet a few conditions, you are compliant by definition. There is no concept of “overusing” beyond capacity, unlike the consumption model, where higher usage incurs higher costs.
However, the flip side is that you pay for headroom whether you use it or not. CIOs should be careful to size the capacity commitment wisely – too high, and you’re overspending; too low, and you might constrain future growth or incur penalties if you outgrow the contract.
In practice, IBM’s capacity agreements often span multiple years and may include provisions for adding capacity. For example, if you upgrade hardware or need more MSUs, you can renegotiate the fixed fee accordingly. Many organizations opting for this model have stable growth trends and value simplicity over potential savings from month-to-month fluctuations.
TFP Considerations and Adoption
Both TFP models come with additional incentives that IBM built into the deal. For instance, TFP contracts typically include no-charge or discounted capacity for development and test environments, so spinning up a new test LPAR or running QA workloads won’t increase your bill.
They also often feature “growth buckets” or discounted rates for workload growth. This means that if you bring new applications onto the platform or your usage grows beyond current levels, the incremental MSUs are priced at a lower rate.
These provisions aim to remove the previous disincentives for growth on the mainframe. Under traditional MLC, adding a new digital workload could blow up your R4HA and increase costs; under TFP, IBM wants to encourage modernization on Z by making incremental usage more affordable.
It’s important to note that adopting TFP is a significant contractual change. IBM typically requires customers to be on relatively recent hardware (at least z14 or newer machines) and recent z/OS versions to ensure the metering and tracking technologies work properly. TFP agreements typically span several years, committing both parties to the model, and cover a broad range of software.
For example, you effectively migrate your applicable MLC software products into the TFP contract. As of 2024, TFP has seen strong uptake. Industry surveys indicate that a majority of mainframe customers have either switched to TFP or plan to evaluate it.
A 2024 user survey found that about 68% of mainframe shops were running or preparing to run under a TFP model, showing rapid adoption in just a few years. This momentum suggests that many CIOs view TFP as a way to rein in unpredictable costs and align mainframe economics with the transparency of cloud pricing.
That said, TFP is not automatically a cost saver in all cases – its value depends on your environment. Some organizations with very flat usage patterns found that traditional MLC with sub-capacity already worked efficiently for them, so moving to TFP might not drastically cut costs, but could still provide simplicity.
Others have used the possibility of TFP as leverage in negotiations with IBM to get better discounts under the old model. Each CIO should carefully model their workloads under both MLC and TFP scenarios. Understanding your true capacity needs and growth projections is essential before signing on to a TFP deal.
Engaging an independent IBM licensing expert (such as Redress Compliance) can help validate IBM’s proposals and ensure that the chosen model (whether sticking with MLC or moving to TFP) is optimized for your business.
Cost Optimization Strategies for IBM Z Software
Controlling mainframe software costs requires a combination of technical and contractual strategies. Below are key approaches to optimize IBM software expenses without compromising compliance:
- Leverage Sub-Capacity and Capping: If you remain on the traditional MLC model, make full use of IBM’s sub-capacity pricing – it ensures you only pay for the capacity you truly use. Analyze your peak workload drivers and use intelligent job scheduling or soft capping tools to smooth out spikes. For example, stagger batch jobs or heavy report runs so they don’t all run at the same time. Careful capacity planning can prevent occasional surges from becoming budget busters. Just be sure any capping does not impact critical service levels; the goal is to reduce unnecessary peaks, not to throttle legitimate business transactions.
- Optimize Performance to Reduce MSUs: Work with your IT operations teams to identify inefficiencies in mainframe workloads. Even small improvements in application performance or data access can lower CPU consumption, which directly translates to MSU savings. Tactics include tuning database queries, archiving or purging inactive data, and ensuring applications are compiled with up-to-date, optimized compilers. IBM and third-party vendors offer tools to analyze and optimize mainframe workload efficiency (for example, optimizing how CICS or Db2 utilize CPU). Reducing the CPU time required for key tasks will permanently lower your software’s run rate.
- Exploit Specialty Processors (zIIP/zAAP): IBM Z systems offer specialty engines, such as the IBM z Integrated Information Processor (zIIP), that can offload eligible workloads, including certain DB2 analytics, Java, or encryption tasks, from the general processors. Work that runs on zIIPs or zAAPs does not count toward MLC MSU consumption, since IBM does not charge MLC for cycles on those specialty engines. By reconfiguring or updating software to utilize zIIP processors where possible, you can reduce the load and cost on regular CPUs. Many customers have saved money by moving SQL processing, XML parsing, or other workloads to zIIPs. The hardware investment in specialty engines can often pay for itself via software cost avoidance. Just ensure you stay within IBM’s guidelines for what workloads are eligible for offload, as pushing non-eligible work to zIIPs would violate compliance.
- Evaluate Tailored Fit Pricing: As discussed, TFP can be a game-changer for cost optimization, especially if your usage patterns are dynamic. CIOs should periodically re-evaluate whether sticking with MLC or switching to TFP makes sense. If your team is spending excessive effort micro-managing usage to control costs, that is a strong signal to consider TFP’s simpler models. Calculate a side-by-side comparison: what would your last 12 months of software cost under an Enterprise Consumption deal? What would it be under Enterprise Capacity? If the numbers look favorable (or even just break-even but with operational benefits), it may be worth opening discussions with IBM. Be cautious with timing – you may get the best deal near a hardware upgrade or contract renewal cycle. And if you do move to TFP, optimize your baseline before committing: for example, eliminate any unnecessary workloads or improve efficiency before IBM measures the usage that will set your TFP rate.
- Use IBM’s Cost Management Tools and Programs: IBM provides tools like the Sub-Capacity Reporting Tool (SCRT) and Resource Measurement Facility (RMF) reports that help you track and understand your mainframe usage. Use these regularly to spot trends. Additionally, stay informed about any IBM programs that could reduce costs. For instance, IBM’s earlier “Application Development and Test Solution” offered affordable pricing for dev/test systems under TFP. Under MLC, IBM had offerings such as mobile workload pricing and country multiplex pricing, which consolidate usage across multiple machines. Ensure you are taking advantage of any program for which you qualify. Sometimes, simply upgrading to a newer machine or a newer version of z/OS can make you eligible for a more favorable pricing metric.
- Negotiate and Right-Size Contracts: Don’t treat your mainframe software billing as a fixed cost. Much like other IT spend, it can be negotiated and optimized. If your mainframe footprint is shrinking (perhaps due to offloading some applications), engage IBM or an independent licensing consultant to adjust your MLC baseline or commit to a lower capacity tier. Conversely, if you anticipate growth, negotiate pricing for that growth upfront. For example, IBM might offer a stepped discount for anticipated increases, rather than surprising you with higher bills later. Consider pursuing an Enterprise License Agreement (ELA) or a bundled arrangement if you use a wide range of IBM software – consolidating contracts can sometimes lead to overall discounts. Always approach renewal time as an opportunity to seek better terms, armed with data about your past usage and future needs. Independent IBM licensing experts, such as Redress Compliance, can provide valuable benchmarks and negotiation insights during this process.
- Retire or Reallocate Unused Software: Mainframes often run dozens of IBM products, some of which may be used infrequently. Audit your environment for any software that is installed and billed via MLC but delivering marginal value (perhaps an old tool or subsystem that few applications use now). If it’s not needed, consider uninstalling it to remove it from the billing calculation, or at least downgrading its usage. IBM MLC pricing is product-specific; eliminating one product from a partition can remove its MSU consumption from your bill. Just be careful to follow IBM’s proper procedures to cancel that license entitlement to avoid compliance issues. Similarly, consolidate workloads onto fewer LPARs when possible – fewer separate peaks can mean a lower combined peak due to economies of scale in a single LPAR or sysplex.
Compliance and Audit Considerations in 2024
Optimizing cost must be balanced with strict license compliance. IBM software audits are a reality that CIOs should proactively plan for. IBM has a formal audit clause in its contracts and actively audits customers to ensure that all usage is licensed.
In 2025, several factors are known to trigger IBM license audits or license reviews: a significant drop in annual spending with IBM, major infrastructure changes (such as an upgrade to a new mainframe model), mergers or acquisitions (which often create licensing complexities), or simply time elapsed since the last audit. Below are best practices to maintain compliance and be audit-ready:
- Maintain Accurate SCRT Reporting: For mainframe sub-capacity licensing, submitting your SCRT reports on time to IBM every month is non-negotiable. Missing a report or having inconsistent data is one of the fastest ways to raise flags. IBM can treat a failure to report as non-compliance – in the worst case, charging you as if at full capacity for that period. Ensure your team has automated and validated the SCRT process. Cross-check the SCRT output for anomalies (e.g., unexpected spikes) and address any issues before submitting. Keep historical reports and audit trails – this is your evidence of proper licensing in an audit.
- Track Entitlements and Deployments: Know exactly what IBM software you are entitled to use (and on which machines) and compare that to what is installed and running. This configuration management is vital. Keep a centralized inventory of all IBM Z software licenses your organization owns, including the license capacity (e.g., number of MSUs or users, as applicable) and the sites or LPARs where they are deployed. Update this whenever there are changes, such as upgrades, new LPARs, or workload moves. During an audit, IBM will request this information. Having it accurate and ready not only speeds up the process but also demonstrates your control over the environment.
- Conduct Internal License Reviews: Don’t wait for IBM to audit – perform your own “DIY audit” at least once a year (some experts even recommend monthly mini-audits for mainframe licensing). This means reviewing SCRT reports, verifying that no unlicensed software is running, and checking that necessary license adjustments were made with any capacity upgrades. An internal audit might involve running IBM’s utility reports, such as the IBM Consumption and Compliance Tool (if available), or simply analyzing SMF data, to ensure no surprises. By doing this, you can catch and correct issues (such as a product that was turned on for a test and forgotten) before IBM’s auditors do. It’s also wise to review IBM’s Passport Advantage records or license certificates to confirm you have paperwork for all in-use products.
- Watch for Audit Triggers: Be mindful of situations that commonly lead to audits so you can prepare in advance. For example, if your organization undergoes a merger or divestiture, anticipate that IBM will be interested in how licenses are being transferred or split – engage your IBM contracts team or an outside expert to ensure entitlements are properly assigned, and consider notifying IBM of changes to stay transparent. If your IBM software spend has decreased significantly (perhaps due to rightsizing or migration), expect IBM may inquire, so ensure genuine reductions in usage justify the reduction and that all usage is still covered. Similarly, if you are nearing the end of a major contract or declining to purchase an upgrade, IBM may initiate a review to ensure everything is compliant before renegotiation. In all these cases, having your records in order will allow you to respond confidently.
- Educate and Enforce Compliance Practices: Ensure that your technical staff understands the importance of license compliance. For instance, system programmers should know not to run IBM software trials or enable features in production without proper licensing. Application teams should be aware that deploying a new workload on the mainframe isn’t just a technical decision but also a licensing one (it could increase MSU usage or even require a new product license). Establish a governance process where a licensing subject matter expert reviews any new mainframe software installation or capacity change. The organization should treat IBM license compliance with the same rigor as financial compliance, with documented processes and management awareness.
- Engage with Independent Licensing Expertise: IBM licensing rules (for mainframes and beyond) change over time, and it can be challenging to keep up with all the nuances. Consider engaging independent IBM licensing experts, such as Redress Compliance or similar firms, to assist with regular compliance health checks and advise on complex scenarios. These specialists can also be invaluable if you do receive an official audit notice from IBM – they can help you respond appropriately, gather the right data, and negotiate any findings. Importantly, an independent advisor works in your interest (unlike IBM’s team, whose goal is to capture revenue). Their guidance can help you navigate gray areas and avoid overpaying for compliance gaps that could have been lawfully mitigated.
- Stay Current with IBM Policies: IBM occasionally updates its licensing policies, tools, or metrics. For example, IBM might introduce a new version of SCRT, change how certain workloads are defined (e.g., what qualifies for offload to zIIP or a new “container” pricing metric), or roll out new licensing programs. Keep an eye on IBM announcements and discussions in the mainframe community’s user groups. In 2024, ensure you are aware of any TFP refinements that IBM has made (IBM has expanded TFP to include hardware and new workload categories) and any changes to sub-capacity rules, such as required versions or patches for the operating system. Adhering to the latest requirements not only keeps you compliant but might also provide opportunities for cost savings if new programs are more favorable.
By following these practices, CIOs can significantly reduce the risk of an unpleasant surprise during an IBM audit. The overarching theme is proactive license management – know your usage, know your rights, and maintain control over both.
This discipline, combined with the cost-optimization measures from the previous section, will position your organization to get the most value out of the mainframe at the lowest reasonable cost, all while remaining in good standing with IBM.
CIO Recommendations
Finally, here is a summary of actionable recommendations for CIOs overseeing IBM mainframe software licensing:
- Assess Your Licensing Model Fit: Regularly review whether the traditional MLC model or Tailored Fit Pricing (Based on Consumption vs. Capacity) is most cost-effective for your organization. Analyze workload patterns (peak vs. average usage) and run cost models for different scenarios. Make an informed choice to either stay the course or engage IBM about a TFP contract, based on data – don’t simply stick with the status quo if a better option exists.
- Optimize Capacity and Workload Management: Instruct your IT operations teams to actively manage mainframe workload placement and timing to avoid unwarranted peaks. Implement capacity planning tools and weekly monitoring of MSU usage. Treat MSU like a precious resource – for example, set performance tuning goals to reduce the CPU usage of key transactions. Ensure that any available cost-saving technologies, such as zIIP processors or updated optimization software, are evaluated and used where appropriate to reduce billable usage.
- Strengthen License Governance: Establish robust internal processes for managing IBM licenses. Require that any changes to mainframe hardware, LPAR configurations, or software installations go through a license compliance review. Maintain documentation of all IBM software contracts, and verify that your usage aligns with entitlements. Consider appointing a dedicated mainframe license manager or expanding the SAM (Software Asset Management) team’s scope to cover mainframe in detail. This governance will pay off by preventing license drift and ensuring preparedness for audits.
- Engage Expert Help When Needed: Don’t hesitate to leverage external experts for IBM licensing. Independent advisors such as Redress Compliance can provide an unbiased assessment of your license position and identify optimization opportunities that vendors might not reveal. Use them especially during contract negotiations or if you receive an audit notice – their specialized knowledge often leads to better outcomes (cost savings, favorable terms, or reduced penalties) than going it alone. The cost of expert advice can be small in comparison to the potential savings or risk mitigation in the IBM mainframe context.
- Plan for Audits and Mitigate Risks: Assume that an IBM audit or license review will happen at some point and prepare accordingly. Conduct regular self-audits of mainframe software usage and proactively address any compliance issues. If you detect any areas of exposure (for example, a period where SCRT wasn’t run properly, or an orphan LPAR that wasn’t accounted for), address them before IBM does – this could mean purchasing additional license capacity or reconfiguring to ensure compliance. Being honest and proactive internally means that if auditors come knocking, you’re ready and confident.
- Budget for Mainframe Software Intelligently: Given that software licensing is a major portion of mainframe TCO, treat it as a strategic budget item. Forecast your MSU consumption and costs for the year and track against that forecast quarterly. Use financial management techniques like show-back or charge-back to internal business units, if applicable, to encourage the efficient use of mainframe resources. When departments see the cost of the cycles they consume, they may be more inclined to optimize their programs. Also, set aside a contingency budget for any true-ups or growth – this avoids panic if usage surges for a legitimate business reason.
- Stay informed about mainframe licensing trends: The landscape of IBM mainframe licensing is constantly evolving. Keep yourself and your team updated on the latest offerings, including IBM’s future pricing initiatives, changes in contract terms, and even competitive licensing models from third-party ISVs, if relevant. Attend mainframe user groups or webinars focused on licensing. In 2024, for example, many peers are discussing their experiences with TFP – learning from their lessons (what worked well and what to negotiate carefully). By staying current, you can anticipate changes (such as IBM’s next move, like usage-based pricing for new products or new audit policies) and not be caught off guard.
By implementing these recommendations, CIOs can better control their IBM mainframe software costs while avoiding compliance landmines. The mainframe platform, with its unmatched reliability and throughput, can continue to be a strategic asset. With savvy licensing and cost management, it can also remain financially sustainable in the modern IT portfolio.
