Reducing MIPS without leaving the mainframe

← All posts

Mainframe cost is what starts most modernisation conversations, and mainframe exit is what most vendors propose in response. The gap between those two things is where a lot of budget gets wasted, because an exit programme takes years to deliver savings and the cost pressure is usually this fiscal year.

There is a large amount of cost reduction available without moving anything. Some of it is infrastructure work. A meaningful share of it is in the code, which is where it gets ignored, because nobody owns “the application burns more cycles than it needs to” as a line item.

This post covers where mainframe consumption actually goes, what reduces it, and how to tell which of those levers apply to your estate.

Understanding what you are actually billed for

Before optimising anything, it is worth being precise about the mechanism, because the optimisation target depends on the pricing model.

Capacity, consumption and the four hour average

Traditional sub-capacity licensing charges against a rolling four hour average of MSU consumption. Under that model, the only consumption that costs money is consumption during the peak interval. Work moved out of the peak, or flattened across a wider window, reduces the bill even if total consumption is unchanged.

IBM’s Tailored Fit Pricing alternatives change that logic. The Software Consumption Solution prices against MSUs consumed rather than a rolling peak, which removes the need to architect around capping and means reductions anywhere in the cycle count. The Hardware Consumption Solution addresses capacity for demand spikes. There is also a solution aimed specifically at development and test workloads.

The practical consequence: under a peak-based model, workload scheduling is a first-order lever. Under a consumption model, total efficiency is. Teams frequently carry optimisation habits from one model into the other and are surprised when the savings do not appear.

Specialty engines

Work eligible to run on specialty processors, most commonly zIIPs, does not attract the same software charges as work on general purpose processors. Java workloads, certain Db2 processing, XML handling and various system functions are eligible in whole or part.

Two caveats that get skipped in vendor material. Eligibility is not the same as execution: eligible work only runs on a specialty engine if one is available when it is dispatched, and understanding the actual redirection rate requires measurement rather than assumption. And the savings depend on the pricing model, because a peak-based model only rewards redirection that lowers the peak.

Tiering

Most IBM and vendor pricing is tiered, with the first units costing more than the marginal ones. That means a percentage reduction in MSUs does not translate into the same percentage reduction in cost. The savings come from where you land on the curve, which is why modelling the bill matters more than celebrating a consumption number.

Infrastructure levers

These are the ones the systems programming team usually already knows about, listed for completeness because an application-side conversation goes better when it does not ignore them.

Workload placement and LPAR configuration

Assignment of logical partitions to physical resources, dispatch priorities, and matching online and batch configuration to the shift that is actually running are all available without touching an application. Teams that have not revisited these after a hardware generation change frequently find several percent sitting there.

Scheduling against the peak

Under peak-based pricing, moving discretionary work out of the peak window is the change with the largest effect available. The obstacle is rarely technical. It is that job dependencies are documented as a schedule rather than as actual data dependencies, so nobody is confident which jobs genuinely must run when.

Establishing the real dependency graph, rather than the inherited one, is analysis work. It is also the same artefact that any future batch modernisation requires, which we cover in everything on the mainframe that is not COBOL.

Data movement

Extracting large volumes off the platform for downstream analytics consumes cycles at both ends. Where processing can occur against the data in place, the transfer overhead disappears. This is an architectural decision rather than a tuning one, but it belongs on the list because ETL volume is a common and largely invisible consumer.

Application levers: where the code costs money

This is the part that goes unexamined, because the people who understand cost and the people who understand the code are usually in different reporting lines.

Compiler currency

This is the largest single application-side lever on most estates, and it requires no source changes.

Each IBM Z generation adds instructions and facilities. Compilers exploit them through architecture level options. Code compiled against an older architecture level runs correctly on new hardware and leaves capability unused, which shows up as cycles consumed that a current compiler would not have spent.

The version position matters here too. Enterprise COBOL 4.2 left standard support on 30 April 2022 and 6.1 on 30 September 2022. Enterprise COBOL 6.3 left standard support on 30 September 2025, with extended availability to 30 September 2028. Estates that completed a version 4 to version 6 move several years ago and stopped are now behind again.

The practical caution: recompiling under a version 6 compiler is stricter about numeric validity than version 4 was, and data that was invalid but tolerated can behave differently afterwards. That risk is manageable through static analysis before the recompile and output comparison after it, but it should be planned rather than discovered. We cover it in what breaks when you recompile old COBOL.

Code that does work nobody needs

Every long-lived estate accumulates consumption with no business purpose.

Reports produced on a schedule that no recipient reads, often because the recipient left and the distribution list was never revised. Programs that read an entire file to extract a small subset because the selective access path was added after the program was written. Sort steps that reorder data already in the required order. Intermediate datasets written and immediately read by the next step. Validation logic executed several times across a job stream because each program was written defensively and nobody owns the chain.

Finding this requires analysis rather than intuition. A dependency and data flow map across the batch estate shows which outputs are consumed and which are produced and discarded, and which processing is repeated.

Dead code

Programs that no job invokes, paragraphs no path reaches, copybooks nothing includes. Dead code does not consume cycles directly, but it inflates compile time, recompilation scope during currency work, and the surface area of every subsequent analysis.

The blocker on removal is always confidence. Nobody deletes a program they cannot prove is unused. Compiler-grade reachability analysis produces that proof, which converts a permanent backlog item into a decision.

Algorithmic and access path issues

Some consumption is genuinely algorithmic: table searches that are sequential where a binary search would serve, repeated lookups that could be held, database access patterns established before the data volumes grew by two orders of magnitude.

These are found through profiling combined with code analysis. Profiling alone tells you which program burns the cycles; analysis tells you why, which is what makes the fix actionable.

How the two sides fit together

The most effective cost programmes we see run infrastructure and application work in parallel rather than sequentially, for a reason worth stating.

Infrastructure levers deliver faster and plateau. Once placement, priorities and scheduling are tuned, the remaining consumption is genuinely the work the applications do. Application levers deliver more slowly and keep giving, because a program that stops doing unnecessary work stops doing it permanently, including after the next hardware upgrade.

The sequencing that works: measure first, take the infrastructure wins while the analysis runs, then act on the application findings with evidence behind them.

What a cost analysis actually produces

For estates that have not done this, the output is usually more actionable than expected.

• A consumption profile by program and job, showing where cycles concentrate. On most estates a small number of programs account for a disproportionate share.
• A dependency map showing which batch work genuinely depends on which, distinguishing real data dependencies from scheduling convention.
• A reachability report identifying programs, paragraphs and copybooks that no live path invokes.
• A currency position showing which compiler versions are in use across the estate, and which components would benefit most from recompilation.
• A duplication report showing logic implemented multiple times, which is both a cost and a maintenance finding.

None of that requires a decision about the platform’s future. It is useful whether you intend to stay for twenty more years or leave in three.

When cost reduction is the wrong frame

Two situations where this work should not be sold as cost reduction.

If the driver is that a small number of people understand the estate and they are approaching retirement, cost is not the problem. Knowledge concentration is, and it is addressed through extraction and documentation rather than through tuning.

If the driver is that the business cannot ship changes fast enough, cost is also not the problem. Structure is. A program nobody dares modify is expensive in a way no MSU report captures. The realistic options there are set out in 4 ways to modernize legacy code.

Where the cycles actually go

Cost conversations improve substantially once someone has looked at consumption by program rather than by partition. The pattern on most batch estates is consistent enough to be worth describing.

Concentration

Consumption is rarely evenly distributed. A minority of programs typically account for a large majority of cycles, and within those, a smaller number of specific operations do. That concentration is good news, because it means a bounded amount of analysis can address a large share of the cost.

The programs at the top of that list are frequently not the ones anyone expects. Teams tend to nominate the programs that are slow, which correlates with elapsed time rather than with cycles consumed.

The categories worth separating

• Genuine business processing: the calculations, validations and transformations the business actually requires. This is the floor.
• Data movement: reading, writing, sorting and copying. A large share of most batch estates, and the category where redundancy accumulates fastest, because each program was written to read what it needs without knowing what the previous step already read.
• Repeated work: the same validation, lookup or derivation performed several times across a job stream because each program is defensive and no one owns the chain. On long job streams this is frequently substantial.
• Work with no consumer: output produced and never read, intermediate datasets written and discarded, reports whose distribution lists are historical.

Only the first category is irreducible, and on an estate that has not been examined for a decade it is often a smaller share of the total than anyone assumes.

Why intuition fails here

The waste was introduced incrementally, by competent people, each making a sensible local decision. No single change was wasteful; the accumulation is. That is exactly the pattern human review does not detect, because every individual program looks reasonable, and exactly the pattern cross-estate data flow analysis does detect.

Getting the measurement right

Acting without measurement produces optimisation of the wrong things, which is worse than doing nothing because it consumes credibility.

The data sources

Consumption reporting at the partition and workload level comes from standard system measurement facilities and the sub-capacity reporting used for licensing. That establishes the financial picture.

Program-level attribution requires job-level accounting data joined to the job and step structure, which requires the JCL and scheduler definitions to be parsed. This is the step most organisations skip, and it is the one that makes application-side work targetable.

Static analysis supplies the explanation: which access paths are used, where the table searches are, where the same logic appears several times, what nothing calls.

Joining them

The useful artefact is a single view linking cost to program to code characteristic. Without it, the finance conversation and the engineering conversation use different units and never meet.

Measure before and after, on the same basis

Savings claims that compare different periods, different workload mixes or different pricing models do not survive scrutiny. Establishing the measurement basis before any change is made is what makes the result defensible internally.

Making savings stick

Cost programmes frequently deliver a reduction that erodes over the following two years. Three practices prevent that.

Attribute consumption to applications

When no application owns its consumption, nobody is accountable for growth. Attribution does not require chargeback; it requires visibility. Teams that can see their own consumption trend behave differently from teams that cannot.

Put a cost check in the change process

The largest source of erosion is new work added without anyone assessing its consumption. A lightweight check at design review, asking what a change adds and whether it duplicates existing processing, costs very little and prevents the accumulation restarting.

Keep the analysis current

The dependency map, reachability report and duplication analysis go stale as the estate changes. Refreshing them periodically is inexpensive once the first pass exists, and it keeps the next optimisation cycle from starting from zero.

Separate the one-off from the structural

Tuning and scheduling changes deliver once. Structural changes to the code deliver permanently, including after the next hardware upgrade. Reporting them separately prevents the organisation from concluding that the whole programme was a one-time effect.

Building the internal case

Cost work competes for attention with delivery work, and the framing that wins is rarely the technical one.

Lead with the measurement gap

Most organisations have a cost picture at the partition level and none at the program level. Stating that plainly, as a visibility problem rather than an efficiency problem, tends to get further than a proposal to optimise, because it is difficult to argue for continuing to spend money you cannot attribute.

Size the opportunity before committing to it

An analysis engagement bounded to producing the consumption picture, the dependency map and the reachability report is small, produces a concrete artefact, and converts the subsequent conversation from speculation to arithmetic. It is also useful if the answer turns out to be that the estate is already efficient.

Separate quick and structural

Infrastructure tuning delivers within a quarter and plateaus. Application work delivers more slowly and permanently. Presenting them as one programme with one number invites disappointment when the quick wins land first and then stop.

Expect the findings to be uncomfortable

Analysis of this kind typically surfaces processing that exists for no current reason, outputs nobody consumes, and duplicated logic. Those findings implicate past decisions, and the programme goes better when that is anticipated rather than discovered in a steering meeting.

What this does not fix

Two limits worth being honest about, because overselling this work damages the next conversation.

Structural cost stays structural

If the application is expensive because of what it fundamentally does, tuning and cleanup will not change that materially. Sustained reduction beyond a certain point requires changing the processing itself, which is a development programme rather than an optimisation one.

Platform economics are what they are

Below a certain consumption level, the fixed costs of the platform dominate and further reduction produces diminishing returns on the bill. Organisations optimising toward an eventual exit should understand where that floor sits, because it determines when the exit case becomes compelling rather than merely arguable.

Knowing the floor is also what prevents a cost programme from being judged a failure for reaching it.

A short note on hardware refresh cycles

Cost conversations frequently collide with a hardware decision, and the two are easier to handle together than separately.

A refresh changes the capacity available and the architecture levels the compilers can address, which means the application-side efficiency work and the hardware decision affect each other directly. An estate compiled against an older architecture level does not exploit a new machine fully, so part of the capital spend buys capability the software declines to use.

The sequencing that works is to establish the compiler currency position before the refresh is specified, so that the capacity modelling reflects what the estate will actually consume afterwards rather than what it consumes today. Teams that do this in the other order size the machine against current consumption, complete a compiler upgrade six months later, and discover the sizing assumptions have shifted.

The same applies to the cleanup work. Removing processing that produces nothing, and consolidating duplicated logic, changes the consumption baseline. Doing it before the capacity conversation rather than after gives the organisation a smaller and more accurate number to buy against, and that is a one-time saving that recurs through the whole life of the machine.

A consumption classification that makes waste visible

Cost reporting tells you where cycles went. It does not tell you which of them needed to be spent. Classifying consumption into four categories is what converts a measurement into a work list.

Why the last three accumulate

Every one of them was introduced by a competent engineer making a sensible local decision. A program reads the file it needs because it cannot know what the previous step already read. A program validates its input because it cannot trust its caller. A report was requested once and never cancelled.

No individual decision was wasteful. The accumulation is, and it is invisible to program-by-program review for exactly that reason. It is visible to cross-estate data flow analysis, which is the only method that sees the chain rather than the link.

Turning the classification into a work list

For each of the top consuming job streams, classify the steps. The output is four lists: processing to leave alone, redundant passes to consolidate, repeated logic to lift, and output to stop producing.

The fourth list is the one to act on first. It requires no code change beyond deletion, it is verifiable by asking the named recipient, and it builds organisational confidence that the analysis is telling the truth before anything harder is attempted.

The observation worth checking on your own estate

On estates that have not been examined in a decade, the genuinely irreducible business processing is consistently a smaller share of the total than the people running it assume. That is not a criticism of anyone; it is what thirty years of independent, locally sensible decisions produces. The only way to find out where your estate sits is to measure it.

Common questions

How much can we realistically save without migrating?

It depends heavily on how recently the estate was tuned, which pricing model you are on, and how much accumulated unnecessary processing exists. Published vendor figures vary widely and should be treated as hypotheses to validate against your own bill rather than as commitments.

Is it worth doing this if we plan to exit the mainframe anyway?

Usually yes, for two reasons. Exit programmes take years, and the consumption continues throughout. And the analysis that identifies waste is the same analysis that scopes the migration, so the work is not duplicated.

Does moving work to specialty engines always save money?

Not automatically. Eligible work only runs on a specialty engine when one is available at dispatch, and the financial effect depends on the pricing model. Under peak-based licensing, only redirection that lowers the peak reduces the bill.

Will a compiler upgrade alone reduce consumption?

It can, because current compilers exploit current hardware architecture levels that older ones do not address. The size of the effect depends on how far behind the estate is and what the workload does. It should be measured on your code rather than assumed from a published figure.

How do we find code that does unnecessary work?

Through data flow and dependency analysis across the batch estate, which shows which outputs are actually consumed and which processing is repeated. Intuition and tribal knowledge consistently miss cases here, because the waste was introduced incrementally over decades.

Can we remove dead code safely?

Yes, when reachability is proven by analysis rather than assumed. The reason dead code survives in most estates is that nobody could produce that proof, not that anybody believed the code was needed.

Which consumption class should we attack first?

Output with no consumer, because it requires no code change beyond deletion, it is verifiable by asking the named recipient, and it establishes organisational confidence in the analysis before anything harder is attempted.

How does a hardware refresh interact with this work?

Directly. An estate compiled against an older architecture level does not exploit a new machine fully, so part of the capital spend buys capability the software declines to use. Establishing the compiler currency position before the refresh is specified gives you a more accurate number to size against.

Why does intuition fail at finding this waste?

Because every individual decision that created it was locally sensible. A program reads what it needs because it cannot know what the previous step read. The accumulation across a job stream is what is wasteful, and that is visible to cross-estate data flow analysis rather than to program-by-program review.

How do we stop savings eroding?

Attribute consumption to applications so teams can see their own trend, add a lightweight consumption check at design review, and keep the analysis current. Erosion happens when new work is added without anyone assessing what it adds or whether it duplicates existing processing.

Where to start

Measure before you act, and make the measurement cover the code as well as the infrastructure. Most estates have a cost picture at the LPAR level and no picture at all at the program level, which means the entire application side of the problem is invisible to the people making the decisions.