COBOL & Mainframe · Track 07

Enterprise Server transaction and MIPS models

Enterprise Server is rarely priced on one metric alone. Enterprise Server transaction and MIPS models describe two different ways OpenText can measure the same COBOL workload, and a finding that picks the model least favourable to the buyer, or applies more than one at once, is where the opening number quietly doubles.

Visual COBOL and Enterprise Server reached the OpenText estate through the Micro Focus acquisition that closed on January 31, 2023, and they are governed by the Additional License Authorizations rather than the OpenText EULA. The ALAs define the units a workload is counted in, and for Enterprise Server those units commonly include capacity measures such as cores, transaction throughput, and on mainframe adjacent deployments a MIPS or workload measure. Each model answers a different question, and a finding built on the wrong question for a given deployment overstates the position. Understanding which model the entitlement actually grants, and which the workload actually fits, is the first move in any defense.

What a transaction model measures

A transaction model prices Enterprise Server against the volume of work it processes rather than the hardware it sits on. The unit is some count of transactions over a defined period, and the entitlement caps that volume. The advantage to the buyer is that a transaction model tracks consumption directly, so a workload that runs a known and bounded number of transactions is measured against exactly that. The risk is that a finding can inflate the transaction count by including retries, internal system calls, or test traffic alongside genuine business transactions. The definitional fight under a transaction model is therefore about what counts as a transaction, and that is a fight the entitlement language usually settles once it is read carefully against the ALAs covered in mainframe ADLM metric definitions explained.

What a MIPS or workload model measures

A MIPS model, used where Enterprise Server fronts mainframe adjacent workloads, prices against processing capacity expressed in millions of instructions per second or an equivalent workload unit. This model is closer to a capacity metric than a consumption metric, and it carries the same risk as the core counting examined in what is an Enterprise Server core license metric: it can measure the capacity that is present rather than the capacity the COBOL actually uses. A finding that applies a MIPS figure drawn from total host capacity, when the COBOL workload occupies only part of it, overstates in exactly the way a core scan does. The defense is the same in shape, replacing a capacity figure with evidenced consumption.

The mechanic

A transaction model measures work done. A MIPS or workload model measures capacity available. The two answer different questions, and a finding that applies the capacity model to a workload entitled on transactions, or counts the same workload under both, is double measuring. One workload is owed one metric.

Where the two models collide in a finding

The expensive error is not choosing the wrong model once; it is applying both to the same workload. A finding can present a transaction overage and a capacity overage for one Enterprise Server deployment as though they were separate shortfalls, when they are two descriptions of a single thing. This is a counting error, not an entitlement gap, and it is found by reconciling every counted line back to the entitlement that governs it, the discipline set out in reconciling COBOL entitlements before an audit. When each workload is matched to its single correct metric, the duplicated charge falls away before any negotiation begins.

How the four Rs take the model question down

The defense follows the firm's four Rs. Respond inside the seven day notice window, take the measurement onto a single controlled channel, and stop any vendor script from running before the entitlement is understood. Reconstruct the effective position by reading the ALAs to establish which model each Enterprise Server entitlement actually grants, then match each workload to that model. Rebut the finding line by line, removing any line that applies a model the entitlement does not support or that double counts a workload already measured. Resolve on terms that name the model explicitly for each deployment, so a future audit cannot reopen the same definitional gap. The line by line discipline is the same one set out in defending an Enterprise Server core overclaim line by line.

In a recent engagement

In a recent Enterprise Server engagement, a finding presented both a transaction overage and a capacity overage against a single deployment. Read against the entitlement, the deployment was licensed on a transaction model, and the capacity overage simply restated the same workload in MIPS. Once the duplicated line was removed and the transaction count was corrected to exclude internal retries and test traffic, the defensible figure was a fraction of the opening number. The reduction was characteristic of the firm's record across more than 200 defended audits, where matching each workload to its single correct metric regularly carries a finding toward the 68 percent average reduction and contributes to the more than $90M in claims mitigated against vendor positions.

Reading the model before the measurement

The lesson is that the model is decided by the entitlement, not by the discovery scan. A scan can produce a transaction count and a capacity figure for the same host, and a finding can present both, but only one is the metric the buyer agreed to. Because the noncompliance remedy is priced at then current list, with back maintenance and audit cost recovery stacked on top, a duplicated metric is a duplicated multiplied charge. Reading the model first, before accepting any measurement, is what keeps the finding honest. To have an Enterprise Server finding tested against the model the entitlement actually grants, open a case.

A note on metric overlap with other product lines

Enterprise Server rarely stands alone in an estate, and the same workload can touch product lines measured on entirely different bases. A transaction model expressed in throughput sits beside the capacity models that govern much of the surrounding infrastructure, and a finding assembled across products can carry a transaction count into a place it does not belong. Reading each entitlement on its own terms, and refusing to let one product's metric colour another's, is part of keeping the COBOL position clean. The same discipline that separates a transaction model from a MIPS model within Enterprise Server separates Enterprise Server from the wider estate, which is why the reconciliation work treats every product line as its own counting problem before any total is assembled. A buyer who lets the models blur pays for the blur; a buyer who keeps them distinct pays only for what each model actually measures.

Is your Enterprise Server finding counting the same workload twice?

We read the Additional License Authorizations to establish which model each deployment is entitled on, then remove any line that double measures or applies the wrong metric. To get a defense team on the file, open a case or download the guide to reading the Micro Focus ALAs.

Get The Number Down →

Related field notes

These notes from the COBOL and Enterprise Server mainframe audit defense cluster cover Enterprise Server metrics and the entitlement reading behind them. Each links back to the complete OpenText audit defense playbook for 2026.

If an OpenText or Micro Focus audit notice has arrived, the first seven days matter more than any week that follows them. OpenText Audit Defense is an independent, buyer side practice founded in 2020 by former vendor compliance leadership. We have defended more than 200 audits, reduced the average finding by 68 percent, and mitigated more than $90M in claims against vendor positions. We do not resell OpenText software and we are not affiliated with OpenText Corporation. To open a case, use the contact form on this site.