How to challenge a COBOL core measurement

A core count looks like a fact: the audit produces a number of cores, multiplies by a rate, and the finding follows. Knowing how to challenge a COBOL core measurement means refusing to treat the count as settled, and putting each core through the questions that decide whether it is chargeable at all.

Visual COBOL and Enterprise Server are governed by the Additional License Authorizations rather than the OpenText EULA, having reached the OpenText estate through the Micro Focus acquisition that closed on January 31, 2023. The authorization, not the discovery scan, defines what a core is in licensing terms and which cores consume entitlement. A measurement that reports physical cores from a scan and stops there has measured hardware, not licensed consumption. The challenge described here is the Rebut phase of the four Rs applied to the most expensive metric in a COBOL finding, and it works by asking the questions the raw count skips.

Start by asking what the authorization counts

Before any core is contested individually, the measurement has to be tested against the metric the authorization actually defines. The starting point is what is an Enterprise Server core license metric, because a challenge built on a misunderstanding of the metric collapses under the vendor's own definition. The questions that matter are whether the metric counts physical or allocated cores, whether it recognises sub capacity arrangements, set out in how sub capacity licensing applies to COBOL, and whether it distinguishes runtime cores from development. A challenge anchored in the authorization's own language is far harder to dismiss than one that simply asserts the number feels high.

The questions that take a core count apart

A core measurement is challenged by asking the same set of questions of every host in the estate, and conceding the cores that survive all of them while removing the cores that fail any one.

• Is this host production? Non production hosts may not be chargeable at production rates, a scoping question in COBOL non production and test environment scope.
• Is this host still live? Decommissioned hosts left on the inventory inflate the count, covered in decommissioned COBOL workloads still on the audit.
• Are these physical or allocated cores? A virtualised, constrained instance should be counted on its allocation, examined in how COBOL virtualization affects core counting.
• Is this runtime or development? Development capacity counted as runtime is the conflation set out in Visual COBOL versus Enterprise Server licensing.
• Is this standby or active? A failover node serving no traffic is examined in Enterprise Server high availability and core counts.

Backing the challenge with evidence

A challenge is only as strong as the evidence behind it, and a core measurement is rebutted with records rather than assertions. Configuration data showing allocated rather than physical cores, environment designations showing which hosts are non production, change records showing decommissioning dates, and workload data showing where transactions actually run all turn a contested number into a documented one. Assembling this evidence is the Reconstruct phase that should precede the challenge, described in reconciling COBOL entitlements before an audit and, for runtime cores specifically, in documenting COBOL runtime cores for a rebuttal. The stronger the evidence assembled first, the shorter and sharper the challenge can be.

In a recent engagement

In a recent COBOL engagement, an Enterprise Server core measurement reported the full physical core count of every host the discovery scan touched. Run through the questions above, the count fell apart in stages: several hosts were virtualised with allocations well below their physical capacity, two were non production environments, and one had been decommissioned months before the audit but never removed from the inventory. Each finding was backed with configuration and change records rather than argument. Counting only the live production runtime cores on their real allocation produced a number a fraction of the opening measurement. The reduction came from treating the core count as a claim to be tested host by host, not a fact to be accepted whole.

Holding the corrected count

The end state of a core measurement challenge is a count every line of which the buyer can defend and the vendor can verify. Cores that are production, live, allocated to the workload, runtime rather than development, and active rather than standby remain in the count. Everything else is removed with evidence. Because the noncompliance remedy is priced at then current list, with back maintenance and audit cost recovery stacked on top, each core removed removes a multiplied charge, not just a unit. A disciplined challenge therefore does more than trim the count; it resets the entire finding to defensible capacity. To have a COBOL core measurement challenged host by host and held to real workload, open a case.

Why the core count rewards scrutiny most

Of all the numbers in a COBOL finding, the core count rewards scrutiny most because it is both the most expensive and the most assumption laden. It is expensive because runtime capacity is the higher rate metric. It is assumption laden because a discovery scan reports hardware, and hardware is systematically larger than chargeable licensed capacity once virtualization, environment, lifecycle, and metric are accounted for. The gap between hardware reported and capacity owed is where the opening finding lives, and a structured challenge is how a buyer closes that gap. The full method that surrounds this challenge is set out in the complete OpenText audit defense playbook for 2026.

Related field notes

These notes from the COBOL and Enterprise Server mainframe audit defense cluster cover cores, capacity, and evidence. Each links back to the complete OpenText audit defense playbook for 2026.

• what is an Enterprise Server core license metric
• how COBOL virtualization affects core counting
• documenting COBOL runtime cores for a rebuttal
• can OpenText count all cores against your COBOL license
• defending COBOL against an inflated core baseline

If an OpenText or Micro Focus audit notice has arrived, the first seven days weigh more heavily than any week that follows. 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.