Before you buy more MIPS, find out what your mainframe runs for nothing

There is a conversation that repeats itself in almost every company running a mainframe. Transaction volume grows, consumption follows, the contract approaches its ceiling, and somebody has to choose between expanding capacity or holding back the business.

The question almost nobody asks before that decision is simpler: how much of what the environment processes today still serves any purpose?

In our experience, the answer tends to surprise people.

Waste does not show up in the consumption report

Consumption reports show how much was spent. They do not show how much was spent unnecessarily. That difference stays invisible precisely because nobody owns it.

Environments with decades of operation accumulate routines that outlived the project that created them, reports nobody reads any more, loads feeding systems switched off years ago, jobs duplicated for old contingencies that were never rolled back. Each one consumes window, CPU and the attention of the support team.

Across a set of clean-up initiatives led by Eduardo, a specialist with more than 30 years in mainframe, cards and acquiring, roughly 15,000 obsolete processes were removed. That figure is the aggregate result of several efforts over time, not of a single project — but it gives a sense of the order of magnitude usually sitting there.

Switching things off without breaking anything is a discipline, not a script

The hard part of a clean-up is not finding candidates. It is deciding safely.

A routine with no execution in the last six months looks dead. It might be the year-end close. It might be the contingency plan that runs once every three years and, on the day it runs, has to work. It might be a regulatory requirement that only surfaces during an audit.

That is why decommissioning has to account for:

• Real dependencies, not only the documented ones.
• Execution calendars, including annual cycles and rare events.
• The business function of each process, confirmed with whoever answers for it.
• A rollback path that can be triggered quickly.

A clean-up done in bounded waves, approved by owners and reversible, is slow enough to be safe and fast enough to produce results within the same financial year.

Optimising what stays

Removing the unnecessary is half the work. The other half is making what remains consume less.

In a case from the Bitwise portfolio — a payments operation where transaction growth was degrading performance and delaying critical windows — the intervention combined four fronts:

• Logic review and optimisation of critical COBOL programs.
• Query tuning and DB2 access strategy.
• Restructuring of batch processes with I/O bottlenecks.
• Continuous monitoring of CPU and consumption indicators.

The result in that environment was a 30% reduction in MIPS consumption and 40% in routine processing time. Those are historical numbers from that specific case, with no guarantee of repetition elsewhere, and they do not refer to the clean-up described above.

The practical effect was more interesting than the percentage: essential routines started finishing earlier. Statement generation, online opening, receivables anticipation and scheme file generation all gained slack. And the freed capacity absorbed growth with no new infrastructure or licence spend.

The method matters more than the tool

Any change in a critical environment needs justification, an owner and evidence. The path we follow has five stages:

Diagnose. Scope applications and batch chains. Gather execution history, consumption, failures, relevant contracts and the business calendar. The delivery is an inventory and a baseline — without a baseline there is no provable gain.

Prioritise. Tie waste and bottlenecks to business impact, classifying dependencies and effort. The delivery is a prioritised backlog and a wave plan.

Validate. Confirm with owners whether each process is still needed and define tests, homologation, change and rollback. The delivery is an approved plan.

Execute. Switch off or optimise approved items, record changes and watch production. The delivery is technical evidence and a stabilised scope.

Measure. Compare against the baseline, adjusting for volume, seasonality and calendar. The delivery is a benefits report and the next opportunities.

That last point is the most neglected. Without adjusting for volume and seasonality, any comparison becomes an argument. With the adjustment, the gain stops being an opinion.

When this conversation makes sense

It is worth looking at your environment if:

• The batch window is close to its limit and delays the online opening or other critical deliveries.
• There are old processes with no clear owner and doubt about what can be switched off.
• The business needs to grow and the technology team is under pressure to expand capacity or contracts.
• Recurring failures eat up the support team.

Modernising does not mean replacing everything. In most cases the fastest route to freeing budget is not migration — it is to stop paying for what no longer serves a purpose.