COBOL & Mainframe · Track 07

How COBOL virtualization affects core counting

Almost no Enterprise Server runs on bare metal any more. It runs in virtual machines, on shared hypervisors, in partitions, and increasingly in containers. How COBOL virtualization affects core counting is the difference between counting the physical cores of the host and counting the cores actually allocated to the workload, and that difference is where a virtualised finding overstates the number most.

Enterprise Server reached the OpenText estate through the Micro Focus acquisition that closed on January 31, 2023, and is governed by the Additional License Authorizations rather than the OpenText EULA. The core metric the authorization defines, examined in what is an Enterprise Server core license metric, is the basis for any capacity charge. The trap in a virtualised environment is that a discovery scan often reports the physical capacity of the underlying host rather than the capacity allocated to the COBOL workload. When the COBOL runs in a small partition of a large host, counting the host counts far more than the workload uses.

Why virtualization breaks a naive core count

The reason virtualization complicates core counting is that it deliberately decouples the workload from the hardware. A single physical host might carry dozens of virtual machines, of which only one runs Enterprise Server, and that one might be allocated a handful of cores out of the host's much larger total. A scan that reports the physical host attributes all of those cores to the COBOL workload, even though the hypervisor never lets the workload touch most of them. The same gap appears with sub capacity arrangements, examined in how sub capacity licensing applies to COBOL, where the entitlement is meant to track allocated rather than physical capacity. The defensive question is always the same: how many cores can this workload actually use, not how many cores exist on the box it happens to sit on.

The mechanic

Virtualization separates workload from hardware. A scan that reports the physical host counts cores the COBOL can never reach. The defense is to count the cores allocated to the workload by the hypervisor or partition, with evidence, not the cores present in the chassis.

Where virtualised core counts inflate

The inflation in a virtualised COBOL count comes from a handful of recurring patterns, each of which substitutes physical capacity for allocated capacity.

Physical host counted for a small VM. A virtual machine allocated a few cores counted on the full physical core count of its host.
Cluster wide counting. A workload that can run on any node of a cluster counted across every node at once, related to the standby question in Enterprise Server high availability and core counts.
Containers counted as hosts. Containerised Enterprise Server counted on the underlying node rather than the container limit, covered in COBOL container and cloud deployment licensing.
Non production virtual machines counted as production. The environment question in COBOL non production and test environment scope compounding the virtualization question.
Soft partitions ignored. Capacity caps and resource pools that constrain the workload not reflected in the count.

Counting allocated capacity under the four Rs

Bringing a virtualised core count back to allocated capacity follows the four Rs. Respond inside the seven day notice window and ensure that what reaches the vendor through the single controlled channel includes the virtualization layer, not just a flat list of hosts. Reconstruct the capacity picture by mapping each Enterprise Server instance to the cores its hypervisor, partition, or container actually allocates, gathered as configuration evidence. Rebut the finding wherever it has counted physical host capacity, an entire cluster, or an underlying node where the workload is constrained to less. Resolve on terms that record the allocated capacity, so a future audit does not revert to physical counting. The evidence is decisive, and assembling it is part of the work described in documenting COBOL runtime cores for a rebuttal.

In a recent engagement

In a recent COBOL engagement, an Enterprise Server finding counted the full physical core count of several large virtualization hosts, even though the COBOL workloads ran in virtual machines allocated only a fraction of each host's cores. The opening capacity number reflected the data centre's hardware, not the runtime's footprint. Producing the hypervisor configuration showing the cores allocated to each Enterprise Server virtual machine, and counting only those, brought the capacity down to what the workload could actually use. The genuine allocated cores remained; the unreachable physical cores left the count. The reduction came from counting what the hypervisor gave the workload rather than what the chassis contained.

Holding the count to the workload

The principle of how COBOL virtualization affects core counting is that capacity is what the workload can consume, not what the hardware can provide. In a virtualised estate those two numbers diverge sharply, and the divergence runs entirely in the buyer's favour once it is evidenced. A workload constrained to a partition, a capped virtual machine, or a container limit is counted on that constraint, not on the host behind it. Because the noncompliance remedy is priced at then current list, with back maintenance and audit cost recovery stacked on top, every unreachable physical core removed from the count removes a multiplied charge. Counting allocated capacity is therefore one of the largest single levers available in a modern, virtualised COBOL finding. To have a virtualised Enterprise Server estate counted on allocated rather than physical capacity, open a case.

Why virtualization is the modern core battleground

Virtualization has become the central battleground in core counting precisely because it is so common and so easy to count wrongly. Few estates run COBOL on dedicated bare metal, so almost every Enterprise Server finding now turns on whether the count reflects the hypervisor or the hardware. A vendor scan defaults to the larger, physical number unless the buyer produces the allocation evidence. That makes the virtualization question both high value and reliably present, which is why it sits alongside environment scope and lifecycle as one of the first things to test, as set out in how to challenge a COBOL core measurement and in the complete OpenText audit defense playbook for 2026.

Has a virtualised COBOL workload been counted on its physical host?

We map each Enterprise Server instance to the cores its hypervisor or container actually allocates, and hold the count to the workload, not the hardware. 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 virtualization, capacity, and cores. Each links back to the complete OpenText audit defense playbook for 2026.

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