Reducing IBM MLC Costs
Introduction: IBM Monthly License Charges (MLC) represent one of the largest recurring costs in many mainframe IT budgets. These charges apply to core IBM Z software (like z/OS, CICS, IMS, Db2, and MQ) and are billed monthly based on peak usage.
In practice, IBM measures your highest consumption of processing capacity – typically the peak MSU (Million Service Units) utilization in a month – and uses that to calculate the bill.
This means a short-lived spike in workload can set a high-water mark that you pay for all month. Without active management, a single busy period can needlessly inflate costs, even if average usage is much lower.
The good news is that there are proven ways to control and reduce these mainframe software costs. In this playbook, we’ll explain how IBM’s MLC billing works, and then dive into optimization tactics, workload tuning methods, and negotiation approaches.
The goal is to empower mainframe managers, IT asset teams, and procurement professionals with IBM MLC optimization strategies to strategically and skeptically reduce mainframe software spend without impacting critical workloads.
Read our ultimate guide to IBM Mainframe Licensing (z Systems): Models, Costs, and Negotiation Tips.
1. What is MLC?
MLC (Monthly License Charge) is IBM’s recurring monthly billing mechanism for major mainframe software products. It covers flagship IBM Z software, including the operating system (z/OS) and middleware such as CICS Transaction Server, IMS, Db2 for z/OS databases, and MQ messaging.
Unlike one-time or perpetual licenses, MLC is a usage-based subscription: you pay for the peak capacity you use every month. IBM tracks usage via its Sub-Capacity Reporting Tool (SCRT), which analyzes your system’s SMF records to find the highest rolling 4-hour average MSU consumption for each product. In simple terms, IBM z/OS software billing is driven by the magnitude of workload spikes.
The risk of this model is clear: without careful management, brief workload spikes (for example, a surge of transactions on the last day of the month) can set a new peak that drives up your monthly bill. Even if your overall or average utilization is moderate, that one peak forces you to pay at a high level for the entire month.
Over the course of a year, these “peak-based” charges can significantly inflate IT operating costs. This is why reducing mainframe software cost revolves so much around controlling peaks.
Checklist: To get a handle on MLC, start with the basics every month:
☐ Validate SCRT reports – Review IBM’s monthly SCRT report to confirm what peak MSU values were reported for each product. Ensure the data matches your expectations.
☐ Identify peak drivers – Pinpoint which day and workload caused the MSU peak. Was it an end-of-quarter batch job? An unplanned surge? Knowing the cause guides your optimization efforts.
☐ Link workloads to billing – Create a connection between your capacity planning and operations teams so they understand that when (and where) workloads run directly affects monthly charges. Scheduling and workload placement should be aligned with cost efficiency.
2. Soft Capping Strategies
One of the most direct technical tactics to reduce MLC costs is soft capping. Capping means setting an upper limit on the CPU capacity (MSUs) an LPAR (Logical Partition) can use, to prevent those cost-triggering spikes.
Unlike “hard capping” (which is a strict stop that can halt workloads), soft capping allows some flexibility while still enforcing a usage threshold.
- Manual Soft Capping: In this approach, you define a fixed Defined Capacity for each LPAR. For example, if an LPAR is prone to spiking to 1,000 MSUs, you might cap it at 900 MSUs so that it cannot exceed that rate for billing purposes. This manual setting can immediately flatten extreme peaks – if a workload tries to burst beyond the cap, the system will constrain it to the defined MSU limit (spreading the work over a slightly longer time if needed). The benefit is straightforward: by keeping usage under a set threshold, you ensure the MLC peak cannot exceed that cap. Many organizations see an immediate drop in monthly charges after implementing conservative caps. The risk, however, is that if you set the cap too low or don’t manage it actively, you might throttle a critical application. Important online transactions could slow down, or batch jobs might miss their SLA if the cap holds them back. So manual capping requires careful tuning and monitoring – essentially, you’re trading some performance headroom for cost control.
- Automated Soft Capping: Automated solutions enhance the concept of capping by adding intelligence. IBM’s own z/OS Workload Manager (WLM) and third-party tools (sometimes referred to as Automated Workload capping solutions) can dynamically adjust LPAR capacity in real-time. Instead of static limits, these systems monitor the overall environment and adjust caps on the fly to meet business priorities without exceeding a target cost threshold. For example, if one LPAR running critical work needs more capacity, an automated system might temporarily borrow MSUs from another LPAR that’s idle, so the important workload isn’t capped. Automation essentially “learns” your workload patterns and smooths out usage peaks by shifting resources, all while keeping the rolling 4-hour average within a defined budget level. The benefit is cost savings without the same level of risk to performance – the automation can react in seconds to prevent slowdowns. However, even automated capping needs to be configured correctly (for instance, setting the overall group cap or policy goals) and requires trust in the tool. It’s wise to start with a pilot or off-peak implementation to ensure it behaves as expected in your environment.
When done properly, soft capping (manual or automated) can significantly reduce your MLC bill by preventing runaway peaks. Just remember that the key is balancing cost and performance: never cap truly business-critical workloads to the point of harm.
Most shops implement capping on lower-priority or batch LPARs, or use automation to ensure caps only engage when they won’t impact SLAs.
3. Workload Planning & Optimization
Another high-impact avenue to reduce MLC charges is through proactive workload planning and optimization. Since MLC costs are driven by peak usage, the timing and method of running workloads become critically important.
Here are a few strategies to optimize workloads for lower peaks:
- Batch Job Scheduling: Large batch processes (like daily bulk data updates, billing runs, or backups) often consume a lot of CPU. By moving heavy batch jobs to off-peak hours, you can avoid stacking their resource demand on top of daytime online transaction peaks. For example, instead of running a huge batch at 9 AM when online users are active, shift it to 2 AM or a weekend window when overall usage is low. Intelligent scheduling tools can help find these “quiet” periods. The result is a smoother demand curve with a lower combined peak. Many mainframe sites have saved hundreds of thousands of dollars annually just by reordering when jobs run – essentially using the capacity you’re already paying for at night, and relieving pressure during the peak window.
- Tuning Applications: Optimization at the application level can also curb MSU consumption. This involves reviewing CPU-intensive jobs and transactions to optimize their efficiency. Common techniques include updating legacy code for improved efficiency, optimizing database calls (e.g., ensuring queries utilize indexes and avoiding inefficient loops), and applying performance patches or compiler upgrades that enable programs to accomplish the same work with fewer cycles. Another powerful tactic is to offload work to specialty engines where possible – for instance, leveraging IBM zIIP processors for eligible workloads (like certain DB2 analytics or Java processing). Work that runs on a zIIP does not count toward MLC MSU usage. By tuning and offloading, you not only improve performance but also directly reduce the MSUs recorded by SCRT for billing. It’s a win-win, though it requires collaboration between performance engineering teams and the capacity planners.
- Workload Spreading: If your environment consists of multiple LPARs or mainframe machines, consider balancing workloads across them to prevent isolated spikes. Sometimes, one LPAR may reach a high peak while others remain idle. By distributing workloads more evenly (or consolidating LPARs under a single cost group so that their usage is averaged), you prevent any one partition from becoming a cost outlier. In practice, this could mean running certain reports or CPU-heavy tasks on a secondary LPAR that has spare capacity, rather than on the already busy primary LPAR. Be mindful of licensing: IBM’s SCRT will aggregate usage for a product across all LPARs in a central processor complex (CPC) or across a country if you use advanced pricing, so spreading workload helps mainly when it prevents overlapping peaks. The goal is to flatten the overall load profile by distributing high-demand work evenly across different time periods or systems.
Figure: An example of MSU utilization before and after workload tuning. The red line (“before” optimization) shows a sharp mid-day peak (around 1000 MSUs), which drives up the monthly license charge. The green line (“after” optimization) has that peak reduced and workloads redistributed (peak ~800 MSUs), by shifting some processing to quieter hours.
By flattening the peak in this way, the monthly MLC cost basis drops significantly – in this illustration, the peak MSU was lowered by 20%. Many companies achieve a 10–20% reduction in MLC cost through disciplined workload scheduling and tuning.
The key is consistency: it requires ongoing attention to scheduling as applications change and new workloads are onboarded, but the savings are directly reflected in the IT budget every month.
Checklist: Make workload optimization part of your regular operations review:
☐ Schedule batch off-peak – Ensure large batch jobs or backups run in low-utilization windows (nights, weekends) whenever possible.
☐ Chart peak vs. average – Plot your peak MSU against average usage each month. A big gap means an opportunity to spread out the workload more evenly.
☐ Improve efficiency – Continuously tune applications and consider refactoring jobs to be more CPU-efficient or zIIP-eligible, so they consume fewer billable MSUs.
Use our checklist for Mainframe negotiations, IBM Mainframe Licensing Negotiation: Checklist for Success.
4. Negotiation with IBM on MLC
Technical fixes go a long way, but don’t overlook commercial strategies. IBM is often open to negotiation on MLC pricing and has various licensing models that can mitigate costs if you play your cards right.
Remember that IBM’s goal is to retain your mainframe workload on their platform, so they have incentives to offer relief or alternatives, especially if you are a significant customer.
Here are key models and negotiation points to consider:
- Workload License Charges (WLC): This is the classic MLC pricing model that most mainframe shops have used for years. It sets a per-MSU rate (which can vary by product and machine size) and charges based on your peak MSU usage (sub-capacity). WLC was IBM’s baseline; think of it as the standard list-price approach. If you’ve never actively changed your pricing metric, you’re likely on WLC. It offers volume discounts built in (larger systems have lower per-MSU rates), but otherwise, there is limited flexibility beyond controlling your usage.
- Advanced Workload License Charges (AWLC): IBM introduced AWLC (and similar variants, such as AEWLC for entry systems) on newer hardware generations. Essentially, AWLC offers better price-per-MSU rates to customers on the latest machines (e.g., IBM z14, z15, and beyond). If you have upgraded your mainframe, you may be eligible for AWLC, which could lower costs by a few percentage points compared to the old WLC rates. These are still peak-based charges, but with a slightly friendlier rate card. Be sure to check with IBM if you’re on the optimal metric for your hardware – sometimes customers stick with an old model out of inertia.
- Tailored Fit Pricing (TFP): This is IBM’s newer subscription-style model for mainframe software, introduced over the last few years. TFP essentially eliminates the monthly peak considerations and instead charges a fixed fee or a predictable fee based on an agreed capacity or consumption over a longer term. There are two main flavors: Enterprise Consumption (pay per use, but averaged over, e.g., a year, so short spikes don’t kill you) and Enterprise Capacity (pay a fixed amount for a set capacity, akin to an all-you-can-eat buffet within that size). The primary advantage of TFP is predictability – your software spend becomes more akin to a flat subscription, which can be beneficial for budgeting. It also removes the “penalty” for growth; under traditional MLC, adding new workloads could spike cost, whereas under TFP, you’re encouraged to utilize the mainframe more since you’ve prepaid for a certain level. However, TFP isn’t automatically a win for everyone. If your workloads are variable or trending downward, a TFP fixed model could make you pay for capacity you don’t actually use. And once you sign a TFP deal, you’re typically locked in for several years. Evaluate carefully (with data!) before migrating to TFP – you want to ensure it truly aligns with your actual usage patterns. IBM often provides sizing tools or trial periods to help model this.
In any negotiation with IBM, come prepared with your SCRT data and a clear story of your optimization efforts. Demonstrating that you are actively managing and reducing usage can strengthen your case for better pricing, because it signals you might otherwise consider offloading work (a subtle leverage point).
Also, don’t hesitate to ask IBM for credits or concessions – they will not volunteer discounts, but they often have room to give, especially if you’re upgrading hardware or signing a long-term contract.
For example, if you plan to purchase a new z16 mainframe, ask for a period of dual-run overlap where MLC on the old machine is discounted, or request some technology upgrade credit to offset the increased capacity of the new machine. IBM has programs for this, but you must bring it up.
Buyer’s tip: Always use your data to simulate different scenarios. If considering TFP, run a what-if analysis: look at last year’s MSU peaks and total usage, and calculate what you would have paid under a TFP deal versus traditional MLC.
This informs your negotiation stance. Additionally, align internally with your procurement and finance teams – a unified front with clear requirements (e.g., “we need to cap MLC at $X per year for the next 3 years”) will help in discussions with IBM.
Checklist: Before heading into an IBM pricing discussion, make sure you:
☐ Run cost models – Use your SCRT reports to model costs under different IBM pricing programs (WLC vs. AWLC vs. TFP). Know your numbers better than IBM does.
☐ Assess TFP fit – Only pursue Tailored Fit Pricing if it aligns with your workload stability and long-term plans. If your MSU usage is volatile or decreasing, locking into TFP could result in inflated costs.
☐ Request credits – Proactively ask about credits for hardware upgrades, workload transitions, or as an incentive for signing a multi-year agreement. IBM often has such offerings, but as the saying goes, “if you don’t ask, you don’t get.”
☐ Engage stakeholders – Involve finance and procurement leaders in the strategy. Their backing can help pressure IBM to offer better terms and ensure that any negotiated deal meets corporate cost objectives.
5. Advanced Optimization Levers
Beyond the common tactics, there are additional levers that sophisticated mainframe shops pull to squeeze out more savings on MLC:
- Country Multiplex Pricing (CMP): This IBM offering allows you to treat multiple machines or LPAR clusters within a geographic region as a single, combined pool for billing purposes. Instead of each mainframe incurring its own peak-based charge, your MSU usage is pooled, and the combined peak is what you pay for. Suppose you have two or three mainframes in the same country. In that case, CMP can eliminate redundant peaks (for example, if Machine A peaks in the afternoon and Machine B peaks in the evening, under CMP, IBM would bill you on a single blended peak, not two separate ones). This often reduces the overall cost because it’s unlikely all systems hit their peak at the same time. CMP requires an agreement with IBM to link the systems for pricing, but it’s worth exploring if you operate multiple CPCs – many large enterprises have saved by switching to this aggregated model.
- Aggregation of LPARs: Even within a single mainframe, how you group LPARs for billing purposes can matter. IBM allows the definition of Group Capacity limits where multiple LPARs share a common MSU cap. By consolidating LPARs into a group, you ensure their combined usage stays within a set boundary and avoid one stray LPAR driving a charge by itself. This is similar in spirit to CMP but on a smaller scale – it’s about managing capacity at a group level. Additionally, consider consolidating or eliminating low-utilization LPARs if possible; sometimes, many small LPARs, each with a minimal amount of usage, collectively cause unnecessary overhead. Simplifying the LPAR layout can create efficiencies in how the SCRT sees your usage. The principle is to avoid paying for “fragmented” peaks across many partitions.
- Technology Upgrade Credits: IBM wants you on the latest hardware, and they know software costs can be a barrier when upgrading (because a faster machine could let you run more MSUs, potentially raising your MLC). To ease this, IBM often provides credits or temporary relief on MLC when you purchase a new mainframe. For example, under certain programs, you may receive a waiver of your MLC charges for a few months or a one-time credit that offsets increased capacity. Always inquire about these when doing a hardware refresh. A savvy move is to time major optimizations alongside a hardware upgrade – if you’re reducing MSU usage via tuning, do it before or during the upgrade negotiation and use that to negotiate a lower baseline contract. Essentially, demonstrate to IBM that with the new machine, your peak won’t be as high as it could be, and secure savings upfront.
- Hybrid Models: There is no rule that you must pick a single approach to manage MLC. In fact, the best results often come from a combination of strategies. This might mean combining technical optimizations with a new pricing model. For instance, one strategy is to put stable production workloads under a Tailored Fit Pricing contract (for predictability) while keeping test or unpredictable workloads on traditional MLC with aggressive capping. Another example of a hybrid approach is to implement soft capping and workload scheduling (to trim peaks) for now, while simultaneously negotiating an option to transition to TFP in a year if certain cost targets aren’t met. Mix and match tactics to suit your situation – the ultimate goal is to minimize cost and risk. Every mainframe environment is unique (due to business cycles, growth plans, etc.), so an optimal solution may be tailored to your specific needs. Don’t be afraid to tailor a custom plan with IBM that, for example, provides you with some immediate MLC reductions and a path to a new model down the road. IBM’s contracts can be quite flexible if you come to them with a creative proposal.
By leveraging these advanced levers, organizations often find additional savings beyond the “low-hanging fruit” of capping and scheduling.
It requires a strategic mindset – looking at your mainframe usage holistically and planning 1-3 years, rather than just reacting month by month.
6. FAQs
Q: What is IBM Tailored Fit Pricing, and should I consider it?
IBM Tailored Fit Pricing (TFP) replaces traditional MLC billing with a predictable subscription-like fee. It benefits customers with steady, high MSU usage by providing cost certainty and eliminating peak-based charges. For variable or declining workloads, however, TFP may lock in costs above actual consumption – so evaluate it carefully before committing.
Q: How can I simulate MLC savings with soft capping?
Use your SCRT reports to identify when and where your MSU peaks occur, then model different cap levels against those peaks. Tools like z/OS WLM or third-party automation can help simulate the effect by applying hypothetical caps and showing the impact on the rolling 4-hour average. Often, these simulations reveal potential savings of around 10–20% by smoothing out workloads. Start with a what-if analysis: “If I had capped at X MSUs during the peak window, what would my bill have been?” This approach helps justify capping implementations to management.
Q: Can workload shifting materially reduce costs?
Yes. Shifting workloads – especially batch jobs – away from peak windows can dramatically reduce the monthly peak MSU that drives your bill. It’s common for enterprises to save significant amounts (sometimes hundreds of thousands of dollars annually) by simply rescheduling non-urgent jobs. By spreading out the demand curve and avoiding everyone piling on the CPU at the same time, you reduce the chargeable peak. In short, clever scheduling is one of the simplest and most effective ways to achieve IBM mainframe cost savings.
Q: Are IBM credits available for MLC optimization?
IBM sometimes provides credits or discounts as part of negotiations, but they are not automatic – you must request them and make a compelling case. Typical opportunities for credits include when you upgrade to a new mainframe model, when you commit to a multi-year contract or new pricing program, or when you can demonstrate a significant workload reduction (for example, moving a portion of work off the mainframe or modernizing an application). Always raise the topic during negotiations: ask if any programs or incentives could help with your MLC costs. Strategic customers and those with competitive leverage (such as a threat to migrate workloads off IBM) tend to have the most success in obtaining these concessions.
Q: Does sub-capacity licensing apply to MLC?
Yes, IBM’s MLC uses sub-capacity licensing, meaning you are billed on usage rather than the full machine capacity. In practical terms, even if your mainframe can handle 1000 MSUs, if you only peak at 600 MSUs, you pay for 600. This is why controlling the peak is so important. Sub-capacity licensing is the foundation of MLC pricing – it’s intended to charge you only for what you use. It also means that all the optimizations we discussed (capping, scheduling, and tuning) directly translate into savings by lowering peak utilization. Just remember that IBM’s SCRT is the official record – ensure it’s configured and running correctly so you actually get the benefit of sub-capacity billing for all eligible products.
Read about our IBM Licensing Advisory Services
