IBM Mainframe Optimisation: Nordic Financial Institution Cuts Costs by €7.2M

The Challenge

The Nordic financial services group faces a persistent mainframe cost problem that affects many large-scale institutions operating IBM z-series infrastructure: annual mainframe software licensing costs were growing at 6 percent year-on-year, driven by both legitimate transaction volume growth and significant operational inefficiencies.

The group operates an IBM z16 mainframe running core banking, payments processing, and insurance administration for customers across Sweden, Norway, Denmark, and Finland. The infrastructure runs IBM z/OS, Db2, CICS, and IMS, supporting approximately 14,000 employees and millions of daily transactions.

Three factors drove escalating costs. First, batch processing workloads were running during peak processing hours, consuming expensive general-purpose MSU (Million Service Units) capacity when they could execute during off-peak periods. Second, workloads that were eligible for zIIP (System z Integrated Information Processor) offload were running on general processors due to insufficient tuning and configuration. Third, the group had never systematically optimised SCRT (Sub-Capacity Reporting Tool) baseline calculations for the Rolling 4-Hour Average methodology, leaving the institution paying for capacity far in excess of actual peak requirements.

The cumulative effect: the group paid approximately €24.8M annually for IBM mainframe software licensing, despite peak capacity utilisation that never exceeded 65 percent and average utilisation significantly lower.

The Approach

Redress conducted a detailed mainframe architecture audit and capacity analysis across the entire infrastructure stack, focusing on three distinct optimisation paths: workload scheduling, zIIP offload expansion, and SCRT baseline renegotiation.

Workload Scheduling Optimisation

The first step identified batch processing workloads consuming peak-hour MSU capacity. The group runs daily batch reconciliation, report generation, and data warehouse load processes during the peak 9am-1pm window, incurring maximum MSU charges during the most expensive processing period.

Workload analysis revealed that 65 percent of batch processing could shift to 2pm-6pm window (off-peak capacity) without violating downstream system dependencies or business reporting requirements. The remaining 35 percent could shift to 8pm-midnight window for non-critical reconciliation and background processing.

Implementation involved scheduling policy changes in CICS and IMS job control, coordination with downstream systems to accommodate 4-6 hour reporting delays for non-critical outputs, and capacity buffer adjustments to ensure adequate headroom during the new peak window (2pm-6pm). No infrastructure changes were required.

Result: €3.4M annual reduction in peak MSU capacity charges by flattening the peak hour consumption profile and reducing the Rolling 4-Hour Average baseline used for MSU tier billing.

zIIP Offload Expansion

The institution had configured zIIP offload for basic DB2 SQL processing but had never extended it to the full set of eligible workloads. Audit identified that only 18 percent of zIIP-eligible workloads were actually running on zIIP processors, while the remaining 82 percent ran on general-purpose capacity.

The group's infrastructure supported three categories of offloadable work: DB2 query processing (both OLTP and OLAP), Java-based application processing (running in CICS/Db2 context), and IMS administrative workloads. Each category required distinct configuration changes to enable zIIP routing.

For DB2, this involved enabling CPU-offload eligible SQL statement routing via BIND options and query governor settings. For Java workloads, configuration changes to WebSphere for z enabled zIIP-dispatched processing. For IMS, administrative transaction offload required updates to the IMS message processing control blocks.

The implementation phased zIIP offload across eight weeks to minimise operational risk, with each category enabled and stabilised before the next category began offloading.

Result: zIIP offload expanded from 18 percent to 56 percent of eligible workloads, generating €2.1M annual savings by shifting high-volume processing from expensive general capacity to zIIP processors, which operate at significantly lower per-unit cost.

SCRT Baseline Renegotiation

The third optimisation addressed the institution's MSU tier calculation, which had never been formally optimised. IBM pricing for mainframe software licensing is based on peak MSU consumption during a rolling 4-hour average window. The institution's previous SCRT baseline was calculated based on observed peak capacity from a single month, without systematic smoothing or seasonal adjustment.

With workload scheduling and zIIP offload now in place, Redress recalculated the SCRT baseline using a full year of corrected capacity data, applying the Rolling 4-Hour Average methodology rigorously across all trading days and batch windows.

The new baseline was 40 percent lower than the previous baseline, reflecting both the operational improvements and more accurate peak capacity measurement. This translated directly to a lower MSU tier assignment and unit cost under IBM's capacity-based pricing.

Negotiation with IBM referenced the baseline recalculation, demonstrated the capacity improvements, and proposed a 3-year Enterprise License Agreement with workload flexibility provisions that accommodated seasonal transaction volume variations without tier adjustments.

Result: €1.7M annual reduction through MSU tier renegotiation based on the corrected SCRT baseline and new ELA terms.

The Outcome

The three-part optimisation programme delivered €7.2M in annual mainframe software licensing cost reduction, representing 29 percent of the institution's total mainframe spend.

Cost Savings Breakdown:

• Workload Scheduling Optimisation: €3.4M (47 percent of total savings)
• zIIP Offload Expansion: €2.1M (29 percent of total savings)
• MSU Tier Renegotiation: €1.7M (24 percent of total savings)

Capacity Improvements:

• Peak MSU consumption reduced 31 percent
• zIIP processor utilisation increased from 18 percent to 56 percent
• General-purpose MSU tier reduced by one full tier level
• Rolling 4-Hour Average baseline reduced 40 percent

Contract Outcomes:

• 3-year ELA with workload flexibility provisions (no tier adjustments for seasonal transaction volume variations up to 15 percent)
• Competitive unit pricing applied retroactively to effective date
• Capacity buffer built into contract for growth headroom without MSU tier escalation

The optimisation programme required no infrastructure investment, no application code changes, and no operational service disruption. All improvements were delivered through infrastructure configuration, workload policy adjustments, and contract renegotiation.

Key Takeaways

1. Mainframe Cost Growth Is Not Inevitable: The myth that mainframe costs must grow with transaction volume obscures the reality that 30-40 percent of cost growth typically stems from operational inefficiencies rather than legitimate scaling. Systematic audit identifies these inefficiencies and quantifies savings potential.

2. Batch Workload Scheduling Delivers Immediate Impact: Batch processing during peak hours is expensive and operationally suboptimal. Rescheduling batch to off-peak windows delivers the fastest ROI, typically within weeks of implementation.

3. zIIP Offload Is Chronically Underutilised: Most institutions have configured zIIP for basic DB2 processing but rarely extend it to the full range of eligible workloads. Systematic analysis and phased enablement of Java, IMS, and advanced SQL processing can triple or quadruple zIIP utilisation.

4. SCRT Baseline Optimisation Requires Discipline: Most institutions calculate SCRT baselines based on observed peaks without systematic methodology. Rigorous Rolling 4-Hour Average calculation using full-year data and corrected peak capacity often reveals 35-45 percent baseline reduction potential.

5. Contract Renegotiation Requires Evidence: IBM pricing is complex, but it is negotiable when backed by rigorous capacity analysis and baseline recalculation. Demonstrable capacity improvements, combined with new ELA terms that provide workload flexibility, unlock significant unit cost concessions.