IBM Mainframe Software Cost Assessment: 20-Point Checklist

IBM's policy is binary: if a monthly SCRT report is missing or submitted late, IBM is entitled to charge you as if the mainframe ran at full capacity for that entire month. A single missed report on a 5,000 MSU machine can produce a one-month MLC back-charge equal to several months of optimised billing. Automate SCRT execution via JCL scheduler, set a calendar alert for the 5th of each month, and store outputs in a document management system with a 36-month retention minimum. When IBM's auditors arrive, this is the first document package they request.

SCRT calculates sub-capacity charges based on the Rolling 4-Hour Average (R4HA) MSU utilisation across all declared LPARs. Omitting a production LPAR — even inadvertently — is treated as non-compliance in an audit. IBM's auditors cross-reference SCRT inputs against SMF data and WLM performance records. Any discrepancy triggers recalculated charges at full-capacity rates for the affected periods, plus back-dated Software Subscription and Support. Review the LPAR declaration list in SCRT at every quarterly infrastructure change.

Not all IBM mainframe products are sub-capacity eligible. Products licensed under One Time Charge (OTC) or specific Value Unit metrics do not participate in SCRT-based billing. Reporting an ineligible product through SCRT creates a compliance conflict. Conversely, failing to enrol a sub-capacity-eligible product means you are paying at full-capacity MLC rates unnecessarily. Run IBM's published sub-capacity eligibility list against your current product inventory annually and at every renewal cycle.

IBM allows organisations to define Group Capacity Limits that aggregate multiple LPARs under a shared MSU cap. Without these limits, a batch workload spike on one LPAR can drive the R4HA reading for an entire group, inflating MLC charges for every software product active in that group. Setting Group Capacity Limits acts as an automatic cost ceiling. Most organisations see a 5 to 15 percent MLC reduction simply from implementing group cap configurations they had previously left undefined.

IBM's compliance position is that if a product appears in SCRT output — even a product you believe you have stopped using — it is active and billable. Organisations frequently discover they are paying MLC for products replaced years earlier because the original installation was never formally cleaned. A decommissioning checklist should include: removal from all LPARs, confirmation in IBM's configuration records, removal from SCRT declarations, and retention of the final SCRT report showing zero usage as audit evidence.

MLC charges are determined by the highest R4HA reading in the month. Shifting resource-intensive batch jobs — end-of-day reconciliation, report generation, data loads — to off-peak windows (typically overnight or weekend) flattens the R4HA curve. Organisations that conduct a formal workload scheduling review achieve 10 to 20 percent MLC cost reductions without any hardware or licensing changes. This is arguably the highest-ROI mainframe cost action available and requires only Workload Manager (WLM) policy changes.

TFP replaces peak-based MLC billing with a predictable monthly baseline derived from your trailing 12-month average consumption. For organisations with stable or growing workloads, the Enterprise Consumption model eliminates costly MLC spikes and allows the mainframe to run at full capacity without billing penalty. TFP is not automatically cheaper than optimised MLC — but for organisations that have exhausted workload scheduling improvements or are planning significant transaction growth, TFP can represent 15 to 30 percent total cost savings. The model requires IBM negotiation; do not accept the first TFP proposal without independent modelling.

IBM MLC bills continue for as long as a product is active in the environment, regardless of usage level. Organisations frequently carry MLC charges for middleware, utilities, and tooling products that teams stopped using but never formally terminated. An annual MLC product reconciliation — comparing SCRT output against the IBM billing statement — typically surfaces three to eight products with zero or minimal actual usage. Terminating these products requires formal notification to IBM and is a contractual right; the savings are immediate and recurring.

IBM's standard S&S renewal applies an annual uplift — typically 3 to 5 percent — that compounds over the duration of a mainframe relationship. Over a five-year period, unmanaged S&S uplifts can add 15 to 25 percent to total mainframe software spend above the MLC baseline. S&S terms are negotiable within the context of an ELA or renewal. Locking S&S caps at zero or below CPI for multi-year periods, and bundling S&S negotiation into hardware refresh conversations, delivers the greatest leverage.

Third-party maintenance is less straightforward on IBM Z than on distributed platforms. IBM's mainframe MLC structure links S&S to continued access to version updates and PTFs — not always replaceable by third parties. However, for specific IBM middleware and tooling products where your organisation is on a stable, mature version with no near-term upgrade plan, third-party or self-support can reduce support costs by 30 to 50 percent. This requires a formal compatibility review and legal sign-off, but is a legitimate cost reduction lever for the right product set.

IBM's sub-capacity pricing on distributed platforms is contractually conditioned on continuous ILMT deployment. Without ILMT, IBM is entitled to charge full-capacity PVU licensing — meaning you pay for the total PVU count of every physical server in the estate, not just the VMs where IBM software runs. In large virtualised environments, the difference between ILMT-compliant sub-capacity and full-capacity PVU charges is typically 60 to 80 percent of IBM distributed software spend. ILMT is not optional; it is a contractual compliance prerequisite. Ensure ILMT coverage extends to every new virtualised host at provisioning time, not retrospectively after an audit.

ILMT deployment without active, clean scanning is treated identically to non-deployment in an IBM audit. Common ILMT failure modes include: scans timing out on large environments, bundling calculation errors caused by stale product catalogue data, unresolved "software not assigned" warnings that accumulate without review, and PVU calculation discrepancies caused by missing hardware inventory data. Assign a named ILMT owner, schedule quarterly ILMT health reviews, and resolve all open warnings within 30 days. IBM auditors will request ILMT reports with a clean status — not a list of warnings you planned to address later.

Cloud Paks bundle multiple IBM software components under a single VPC-based entitlement. The common compliance failure is deploying Cloud Pak components in configurations that exceed the licensed VPC count, or activating bundled components that were not intended for use without understanding that activation triggers a licensing obligation. Maintain a live deployment register of every Cloud Pak component in use, cross-referenced against the contracted VPC entitlement. Where architecture is likely to shift between cloud and on-premises, negotiate explicit VPC-to-PVU conversion rights at contract execution rather than after the fact.

Running IBM middleware past its end-of-support date does not immediately terminate your S&S payment obligation — IBM continues billing even for unsupported versions — but it eliminates your entitlement to PTFs, security patches, and fix pack access. More importantly, out-of-support versions create an audit risk: IBM may treat them as evidence of improper installation or contract non-compliance. Map all IBM middleware versions against IBM's support lifecycle data and flag any product reaching end-of-support within 18 months as a renewal or modernisation decision point.

IBM ELAs frequently contain products included as bundle add-ons that are either over-deployed (creating hidden compliance exposure) or never deployed (representing waste that IBM will use to justify bundle pricing at renewal). An annual ELA reconciliation serves two purposes: it prevents compliance surprises by identifying shortfalls before IBM does, and it builds the evidence base to challenge IBM's renewal pricing by demonstrating which bundle components deliver zero value. IBM ELA renewals are not line-item negotiations unless you walk in with data. Without annual reconciliation, you are negotiating blind.

IBM manages its ELA renewal pipeline with structured sales pressure designed to close transactions as quickly as possible. Organisations that engage IBM without adequate preparation time — typically anything less than six months of negotiation runway — accept IBM's first commercial position by default. IBM's standard ELA renewal includes annual price uplifts, bundle components of questionable value, and support terms favouring IBM. Twelve months of lead time allows you to: build your usage baseline, issue a competitive RFP to create leverage, evaluate Tailored Fit Pricing, and engage a specialist advisor without time pressure.

Shared sysplex configurations, common in financial services and insurance, create complex IBM licensing questions around multi-entity software allocation. IBM's licensing rules for sysplex environments can require that software licences cover the entire sysplex rather than individual member systems, depending on product type and how the software is invoked. The risk runs in both directions: under-licensing by assuming LPAR-level allocation when IBM requires sysplex-level coverage, or over-paying by licensing the same product per entity when a single enterprise-wide licence would suffice. Legal entity mapping should be reviewed with an IBM licensing specialist at every major infrastructure change.

M&A activity is one of IBM's most reliable audit triggers. IBM's licensing agreements are entity-specific: software licences held by the acquiring entity do not automatically extend to the acquired entity's users, systems, or deployments. Integrating an acquired company's IBM Z workloads into your existing SCRT environment without explicit licence coverage creates an immediate compliance exposure. Conversely, divestitures require formal licence reassignment. IBM should be notified of any corporate structure change affecting IBM Z deployments within 30 days. Failure to do so is frequently cited in IBM audit findings as wilful non-compliance.

IBM licence audits are typically conducted by Deloitte or KPMG on IBM's behalf. The audit notification letter is formal legal correspondence and initiates a defined information request process. Organisations that respond without a protocol frequently disclose more than contractually required, agree to scope expansions that were optional, and allow auditor-defined data collection methods that favour IBM's position. Your audit protocol should specify: who reviews the notification letter before responding, what data is contractually required versus voluntarily supplied, and at what stage an independent IBM licensing advisor is engaged. The first 30 days of an IBM audit define your negotiating position for the remainder.

IBM's own licensing advisory services, reseller-led reviews, and IBMconducted technology assessments are all conducted by parties whose revenue is directly tied to the outcome. IBM's internal licensing consultants are measured on software revenue. An independent assessment — conducted by an advisor compensated solely by the customer — is the only mechanism that produces an objective picture of where you stand, what you actually owe, and what IBM's commercial position is likely to be. Our IBM mainframe assessments typically surface 10 to 25 percent in identifiable MLC optimisation opportunities alongside an honest compliance gap analysis that gives you real negotiating leverage.