Intelligence

OptiMIPS

The mainframe hides room for optimisation.
OptiMIPS makes it visible and manageable.

AI engine on historical and real-time data · IBM z/OS · Db2, IMS, CICS, batch · on-premise or as an assessment

Ask for a demo The numbers

MIPS load · overnight batch window

Before After OptiMIPS
38%of batch capacity freed up
€2.4Mof cost avoided over 3 years
0 changesto business logic

Figures aggregated from assessments on medium and large z/OS installations. Indicative values, to be verified on each environment.

The video

The product in under two minutes.

Pressing play loads the Biteable player, an external service. Until then the page sends no request to them.

The context

What does the mainframe really cost?

In banking the mainframe still runs the most critical services, and installed capacity is sized for peak usage. But how much of it is actually used, and for what? A precise view is usually missing: a batch written twenty years ago and never revisited can absorb as much capacity as a new line of business.

Peaks that drive the bill

The licensing model makes workload distribution decisive: a few minutes of usage at the wrong moment, or in the wrong environment, can add tens of thousands of euros a year.

Code with no owner

Legacy programs that were never revisited can carry redundant reads, unnecessary sorts and joins that scan whole tables. System resources are consumed with no real benefit to the business.

Batch windows at the limit

Every new regulatory requirement is added to overnight batch windows that are already full, squeezing processing times further.

A fragmented view

Systems staff, application teams and finance each look at different data. Without a shared view of consumption and who it belongs to, it is hard to find the causes of the cost or to agree on what to do.

How it works

Optimise MIPS, cut consumption, free up capacity.

We analyse the historical and real-time data that z/OS already produces, to find where and how MIPS are consumed. We identify the inefficiencies and act on them, measuring the result by comparing consumption before and after each change.

PHASE 01PHASE 02 PHASE 03PHASE 04 InstrumentationAnalysis OptimisationEconomic evidence SMF, RMF, Db2 andCICS logs, collected live. Consumption attributedby job, program, SQL. Targeted rewrites,indexes, scheduling. MIPS before and after,converted into cost avoided. CONTINUOUS CYCLE — EVERY RELEASE IS MEASURED AGAIN No intrusive agent Zero impact on load Business logic untouched Reporting for CIO/CFO

Inside the product

A clear view, from day one.

Three views of the same data: for the people who run operations, the people who design the changes, and the people who judge what it is worth.

Resources, minute by minute

A dashboard follows the rolling four-hour average, flags threshold breaches and lets you reconstruct which processes were running at the moment the cost was set. In the busiest periods anomalies can be spotted and investigated early, before they turn into an outage.

  • Load heatmap by LPAR and service class
  • The jobs behind each peak, reconstructed
  • What-if on moving the schedule
Operations view

Finding the inefficiency in the code

For each program we analyse consumption and identify the most expensive SQL, the repeated reads and the data structures being used inefficiently.

  • Statements ranked by CPU consumed
  • Index and rewrite suggestions
  • Automatic regression on the benefit achieved
Application view

From MIPS saved to money saved

We quantify the cost avoided in MIPS terms, measured by quarter, by application and by line of business.

  • Business case kept up to date automatically
  • Cost attribution by cost centre
  • Export for management accounting
Financial view

Business case

The load profile,
before
and after.

Drag the handle: on the right, the curve after twelve months of OptiMIPS work on a z/OS environment with 2,400 MIPS installed.

R4HA peak
2,180 → 1,352 MIPS
Batch window length
6h 40′ → 4h 05′
Annual licence cost
−38%
Functional releases blocked
0
Before After

Schematic representation of the R4HA profile over a 24-hour window.

Ways of working together

An optimisation path, built around what you need.

From the first analysis of how capacity is used through to workload optimisation, every step starts from the data and concentrates on the areas with the most to gain. The path adapts to the company’s priorities.

EngagementLengthWhat you getYour IT effort
Quick assessment2 weeksLoad map by application and the top 20 actions2 days
Proof of concept6 weeksPilot changes with the delta measured5 days
Ongoing programme12 months +Optimisation plan and permanent oversightrun by us

Frequently asked questions

The questions we are asked
most about OptiMIPS.

Any other questions?
We start with an assessment of the existing environment: how capacity is used, which applications and processes weigh most on consumption, and where the inefficiencies sit. The result is a map of the opportunities with a business case estimating what they are worth. The actual saving depends on the workloads, on the changes identified and on their implementation — which is why every optimisation is measured by comparing consumption before and after.
In a European Tier-1 banking environment, optimisation at application level cut batch consumption in the domain analysed by 20-30%, with reductions above 90% on individual heavy jobs and more than 1,000 MIPS freed from the existing infrastructure, with no change to the system architecture. These are results from one specific application context, not guaranteed benchmarks. Estimating the potential of another environment means analysing its own workloads, applications and usage.
OptiMIPS analyses the telemetry z/OS already produces, and writes nothing to production systems. The platform is available as enterprise SaaS, built on microservices, and runs on Docker and OpenShift. Go-live takes roughly 2-4 weeks from signature; the first useful insights normally need 6-10 weeks, long enough to build a historical base worth analysing.
No. OMEGAMON, AMI Ops and SYSVIEW go on doing their job of monitoring and operational management. OptiMIPS uses the available telemetry to analyse consumption from an application and financial angle, connecting the resources used to the applications and processes that generate them. The point is to add a layer of analysis and cost attribution, not to replace the tools already in place.
The Code-to-Runtime layer reconstructs the relationship between applications, jobs, steps, programs and SQL, and identifies where to act. For each candidate it produces the evidence, the suggested change, the estimated effort and the expected reduction. The proposals are reviewed by our mainframe specialists together with the client’s teams. The decision on what to change, and when to release it, stays with the company and follows the processes it already has.
The Mainframe Copilot is read-only and changes nothing on the systems it analyses. It runs on Rafiki, Add Value’s AI agent platform, and uses a Model Context Protocol architecture to query the OptiMIPS analytics. Access is governed by per-user and per-application permissions, interactions are audited, and it works with whichever language model company policy allows.
Migrating off the mainframe can take years, and throughout them consumption keeps costing money. Analysing how resources are actually used adds a financial view alongside the technical one: which applications are the most expensive, what to migrate first, and which components can reasonably stay where they are. Optimisation does not replace the migration strategy — it gives it something to decide on.

Keep exploring

The other Add Value products

Find out where to act
to optimise what
the mainframe costs.