How core based metrics inflate a Visual COBOL finding

Modern servers carry far more cores than a COBOL workload ever uses, and a finding that counts every physical core on every host will dwarf the runtime the application actually consumes. Understanding how core based metrics inflate a Visual COBOL finding is the first step to holding the number to the licensed runtime, because the gap between the cores present and the cores entitled is where the overclaim lives.

Visual COBOL reached the OpenText estate through the Micro Focus acquisition that closed on January 31, 2023, and like most Micro Focus products it is governed by the Additional License Authorizations rather than the OpenText EULA. Core based metrics are common across the COBOL and Enterprise Server line, and they are powerful for the vendor precisely because hardware has outpaced software: a host provisioned for many workloads exposes a large core count, and a metric that counts that count rather than the runtime entitlement produces a finding several times larger than the deployed use justifies.

What a core based metric measures, and what it should

A core based metric ties the license to processor cores rather than to named users or to a usage volume. The contested question is which cores count: every physical core on every server where the software is installed, or the cores actually made available to the COBOL runtime. Those two readings can differ by an order of magnitude on a modern host. The authorization is the document that settles it, defining whether the metric counts physical cores, allocated cores, or some sub capacity measure, and a finding that defaults to the largest reading without checking the agreement is asserting a position the contract may not support.

The same distinction sits at the centre of whether OpenText can count all cores against your COBOL license, and reading that note alongside this one sharpens the point: presence on a host is not the same as licensed runtime.

Where the inflation enters

Several patterns drive a core based Visual COBOL finding above the defensible figure, and each is a line to test against the authorization rather than a number to accept.

• Physical cores counted as licensed cores. Counting every core on the host rather than the cores allocated to the COBOL runtime.
• Virtualization ignored. Refusing to recognise the partition or virtual machine boundaries that limit the cores available to the workload, a subject we develop in how COBOL virtualization affects core counting.
• Development and runtime conflated. Counting development installs under a runtime metric when the two are licensed differently, as covered in runtime versus development license counting for COBOL.
• Non production hosts swept in. Counting test and lab servers as production capacity without checking what the authorization grants for non production use.

Reconstruct the core position against the authorization

The four Rs apply directly to a core based finding. Respond inside the seven day notice window and route everything through a single controlled channel, so the deployment is described once rather than reconstructed by the vendor from an installation scan. Reconstruct the effective position by reading the authorization for which cores the metric counts and how sub capacity and virtualization are treated, then mapping the actual allocated runtime against it. Rebut the finding line by line where it counts physical cores, ignores partition boundaries, or conflates development with runtime. Resolve on terms that fix the core counting basis so the next audit does not reopen the same hardware. Building this position before any vendor measurement runs is the high leverage move, and our note on reconciling COBOL entitlements before an audit sets out how.

In a recent engagement

In a recent COBOL engagement, a finding rested on a count of every core on a cluster of large hosts, several of which ran the COBOL workload in tightly bounded partitions alongside unrelated applications. Reconstructing the allocated runtime, reading the authorization for how it treated sub capacity, and documenting the partition boundaries brought the counted figure down to the cores the workload actually used. The reduction came from the difference between hardware present and runtime licensed, which is the same difference that inflates most core based findings.

Hold the count to the licensed runtime

With Visual COBOL more than most products, a core based finding depends on whether anyone insists that the metric counts licensed runtime rather than installed hardware. A buyer that accepts a physical core count is paying for processor capacity its application never touches. The defensive discipline is to read the authorization for which cores count, document the allocated runtime and the virtualization boundaries, and rebut every line that treats presence on a host as licensed use. Most of the reduction available on a core based Visual COBOL finding comes from closing the gap between the cores present and the cores entitled, established from the agreement and the deployment together.

Related field notes

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

• can OpenText count all cores against your COBOL license
• how COBOL virtualization affects core counting
• runtime versus development license counting for COBOL
• what is an Enterprise Server core license metric
• how sub capacity licensing applies to COBOL

If an OpenText or Micro Focus audit notice has arrived, the first seven days carry more weight 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.