How sub capacity licensing applies to COBOL

When COBOL runs on a slice of a larger machine, the question of whether you pay for the slice or the whole machine decides the size of a finding. How sub capacity licensing applies to COBOL is the question of when a deployment can be counted on the cores actually allocated to it rather than the full physical capacity of the host, and a finding that ignores a valid sub capacity position charges for cores the workload never used.

Visual COBOL and Enterprise Server reached the OpenText estate through the Micro Focus acquisition that closed on January 31, 2023, and both are governed by the Additional License Authorizations. Those authorizations define how capacity is counted, and in virtualized and partitioned environments the difference between full capacity and sub capacity counting can be the difference between a defensible figure and a finding several times its size. When a discovery scan reads a host it tends to see the whole machine, and a finding built on that view counts every physical core whether COBOL ran on it or not. This article sets out when sub capacity counting applies, where the finding inflates, and how the allocated cores are restored line by line.

What sub capacity counting means

Sub capacity counting means measuring a deployment on the processing capacity actually made available to it, rather than on the full physical capacity of the host it sits on. A COBOL runtime confined to a partition, a virtual machine, or a constrained set of cores consumes only that allocation, and counting it on the full host overstates what the workload uses. The relationship between the host, the partition, and the count is the same one explored in how COBOL virtualization affects core counting, and sub capacity is the principle that lets a constrained deployment be counted on its constraint rather than on the metal underneath it.

Where a finding charges full capacity

The overstatement begins when the scan reads the host and the finding counts every physical core. Several patterns recur around how sub capacity licensing applies to COBOL.

• Full host counted for a partitioned workload. Every core of a large machine charged when COBOL ran in a bounded partition.
• Virtual allocation ignored. A virtual machine capped at a few cores counted on the full hypervisor host.
• Eligible constraint undocumented. A valid sub capacity arrangement charged at full capacity because the constraint was never evidenced.
• Cluster wide counting. Every node of a cluster counted when the workload only ever ran on a subset, tying to Enterprise Server high availability and core counts.

Restoring the sub capacity position under the four Rs

The defense establishes the sub capacity position through the firm's four Rs. Respond inside the seven day notice window, set a single controlled channel, and prevent any vendor script from measuring before the partitioning and allocation are documented. Reconstruct the position by reading the Additional License Authorizations to confirm the conditions under which sub capacity counting applies, then evidence the partition, virtual allocation, or core constraint for each deployment. Rebut the finding line by line, removing any line that counts full host capacity where a documented constraint limits the workload to a subset. Resolve on terms that record the sub capacity basis for each deployment, so a future audit cannot revert to full capacity counting. The reconciliation that organises this work is the one in reconciling COBOL entitlements before an audit.

Why evidence is the whole battle

Sub capacity counting almost always depends on conditions, and the conditions usually require the constraint to be documented in a way the authorizations recognise. A partition that limits a workload to a subset of cores only helps if the limit can be shown, which is why the core measurement covered in what is an Enterprise Server core license metric has to be paired with evidence of the allocation. The finding will count full capacity by default, and only documented evidence of the constraint moves it to sub capacity. Assembling that evidence early, before any vendor measurement runs, is what makes the sub capacity position hold.

In a recent engagement

In a recent COBOL engagement, a finding counted full physical host capacity across an estate where several Enterprise Server runtimes were confined to bounded partitions and capped virtual machines. The defense read the authorizations, confirmed the conditions for sub capacity counting, and evidenced the partition and allocation for each constrained deployment. Once the documented constraints were applied and the full host lines were reduced to the allocated cores, the finding fell to the defensible figure. The reduction was characteristic of the firm's record across more than 200 defended audits, contributing to the 68 percent average reduction and the more than $90M in claims mitigated against vendor positions.

Why the constraint decides the count, not the host

The lesson is that capacity is counted on the allocation, provided the allocation is evidenced, not on the size of the host. Because the noncompliance remedy is priced at then current list with back maintenance and audit cost recovery stacked on top, counting full host capacity where a constraint applies multiplies a charge for cores the workload never touched. Reading the authorizations, evidencing the constraint, and resolving on terms that record the sub capacity basis is what keeps a constrained COBOL deployment counted on its constraint. This is the same discipline that drives the broader reduction in reducing a COBOL finding with workload evidence. To have a COBOL finding tested for a valid sub capacity position, open a case.

Related field notes

These notes from the COBOL and Enterprise Server mainframe audit defense cluster cover virtualization, core counting, and the evidence that supports a sub capacity position. Each links back to the complete OpenText audit defense playbook for 2026.

• how COBOL virtualization affects core counting
• what is an Enterprise Server core license metric
• Enterprise Server high availability and core counts
• reducing a COBOL finding with workload evidence
• reconciling COBOL entitlements before an audit

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.