COBOL & Mainframe · Track 07

Can OpenText count all cores against your COBOL license

When a COBOL finding lands, it almost always counts more cores than the buyer believes it licensed, which raises the question directly. Can OpenText count all cores against your COBOL license, or only the cores the authorization defines as licensed, is the single question that decides most of the number.

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 rather than the OpenText EULA. The short answer to whether OpenText can count all cores is that it can assert any count it likes in an opening finding, but the authorization, not the finding, determines which cores are actually licensable. A buyer who assumes the finding is correct concedes the broadest possible count. A buyer who reads the authorization can usually establish that only a defined subset of cores is countable, and that subset is frequently far smaller than the physical inventory the finding relied on.

What the authorization actually permits

A core based authorization does not simply license a machine. It defines a unit of capacity, and the count is supposed to follow that definition. The definition usually answers whether the metric counts physical cores on the host, allocated cores within a partition or virtual machine, or a sub capacity measure that reflects the capacity assigned to the COBOL runtime. These readings differ widely, and only one of them is what the agreement supports. The reason a finding can appear to count all cores is that the simplest count, every physical core on every host where the software is installed, is the easiest to assert and the most favourable to the vendor. It is also, in many deployments, the least defensible.

The relationship between the metric and the count is set out in what is an Enterprise Server core license metric, and the way a broad reading inflates the number is examined in how core based metrics inflate a Visual COBOL finding. Both make the same point from different angles: the count is a product of the definition, and the definition rarely supports counting everything.

The mechanic

OpenText can assert a count of all cores. Whether it can sustain that count depends entirely on the authorization. The licensable figure is the cores the definition counts, which in a virtualised or consolidated estate is often a fraction of the physical inventory.

Where counting all cores overreaches

The places a core count overreaches are predictable once the deployment is understood. Each represents a category of cores that a blanket count sweeps in and that the authorization may exclude.

Cores outside the partition. Where the runtime executes in a defined partition or virtual machine, physical cores beyond that boundary may not be countable, the subject of how COBOL virtualization affects core counting.
Cores covered by sub capacity terms. Where sub capacity licensing applies, the count follows allocated rather than physical capacity, as explained in how sub capacity licensing applies to COBOL.
Non production cores. Test, development, and disaster recovery hosts are frequently counted as if they were production, when they may be governed separately or not at all.
Decommissioned or idle cores. Hosts retired before the audit period, or cores never allocated to the runtime, sometimes remain in the finding's inventory.

How to hold the count to the licensed cores

Holding a COBOL finding to the cores the authorization actually counts is what the four Rs are built to do. Respond inside the seven day notice window and hold a single controlled channel, so the estate is described once and the vendor cannot assemble the count from fragments. Reconstruct the effective position by reading the authorization for which cores it counts, then mapping the real allocation, the partition boundaries, and the non production split against it. Rebut the finding line by line wherever it counts physical cores it cannot sustain, ignores partitions, or prices non production as production. Resolve on terms that write the core definition down, so the next audit cannot reopen the same blanket count. The discipline throughout is to make the vendor justify every core it counts against the words of the agreement, rather than letting the count stand by default.

In a recent engagement

In a recent COBOL engagement, a finding counted every physical core across a virtualised cluster on the theory that the software was installed cluster wide. The runtime, however, executed in tightly bounded partitions on a minority of the hosts, and the authorization counted allocated cores within those boundaries. Reading the definition and mapping the actual allocation against it established that the licensable count was a fraction of the physical inventory the finding had used. Holding the finding to the cores the authorization genuinely counted removed most of the asserted shortfall, and the reduction came entirely from refusing to accept that all cores were countable.

The finding asserts, the authorization decides

So can OpenText count all cores against your COBOL license? It can put that count in an opening finding, but it cannot make the count true by asserting it. The authorization defines which cores are licensable, and in most modern deployments that definition excludes a great deal of what a blanket count includes: cores outside the partition, cores covered by sub capacity terms, non production hosts, and idle or decommissioned capacity. The defensive task is to read the definition, map the real allocation against it, and require the vendor to justify every core. A buyer that does this rarely pays for all cores, because all cores were rarely licensable in the first place. If you want this read done before you respond, open a case and we will start with the authorization.

Worried a COBOL finding is counting cores you never licensed?

We read the authorization for which cores are countable, map the real allocation against it, and hold the finding to the licensed cores. 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 cores, capacity, and counting. 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 matter more than any week that comes after. OpenText Audit Defense is an independent, buyer side practice founded in 2020 by former vendor compliance leadership. We have defended more than 200 audits, cut 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.