What is an Enterprise Server core license metric

Before a buyer can challenge a core based finding, it has to understand exactly what the metric claims to measure. An Enterprise Server core license metric ties the license to processor cores rather than to users or workload volume, and the whole question of whether a finding is fair turns on which cores the authorization actually counts.

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. Enterprise Server runs COBOL and mainframe style workloads on distributed platforms, and a core metric is a natural fit for production runtime: the license scales with the processing capacity allocated to the workload. The trap is that a core metric is only as fair as its definition, and a finding that reads the definition broadly, counting every core present rather than every core licensed, produces a number well above the deployment.

How a core license metric works

A core license metric assigns a number of licensed cores to the Enterprise Server runtime. In principle the buyer licenses the cores its workload runs on, and the finding compares that entitlement to the cores in use. In practice the definition does the work. A modern server may present dozens of physical cores, only a fraction of which are allocated to the Enterprise Server runtime, and the authorization determines whether the metric counts the physical cores, the cores in the partition or virtual machine where the runtime executes, or some sub capacity measure. Those readings differ widely, and the finding rests entirely on which one the agreement supports.

The mechanics of how a broad reading inflates the number are set out in how core based metrics inflate a Visual COBOL finding, and the same logic applies directly to Enterprise Server.

The questions the definition has to answer

Understanding an Enterprise Server core metric means reading the authorization for the answers to a few specific questions, each of which can move the finding materially.

• Which cores count. Physical cores on the host, allocated cores in a partition, or a sub capacity measure, as covered in how sub capacity licensing applies to COBOL.
• How virtualization is treated. Whether partition and virtual machine boundaries limit the countable cores, the subject of how COBOL virtualization affects core counting.
• What counts as production. Whether non production, test, and disaster recovery hosts are inside the metric or governed separately.
• How high availability is handled. Whether standby and redundant nodes count as licensed cores, a question we take up in Enterprise Server high availability and core counts.

Reading the metric is the start of the defense

The four Rs build on a clear reading of the metric. Respond inside the seven day notice window and hold a single controlled channel, so the deployment is described once. Reconstruct the effective position by reading the authorization for which cores the metric counts and how virtualization, non production, and high availability are treated, then mapping the actual allocated cores against it. Rebut the finding line by line where it counts physical cores, ignores partitions, or sweeps in standby nodes. Resolve on terms that write the core definition down so the next audit starts from a settled basis. Understanding the metric is what makes each of these steps possible; without it, the buyer is arguing about a number it does not fully understand.

In a recent engagement

In a recent Enterprise Server engagement, a finding counted every physical core across a virtualised cluster, although the runtime executed in tightly defined partitions on a minority of those cores. Reading the authorization established that the metric counted allocated cores subject to the partition boundaries, not the full physical inventory. Mapping the actual allocation against that definition reduced the counted figure to the cores the workload genuinely ran on. The reduction came entirely from understanding what the metric measured and holding the finding to it.

Know the metric before conceding the count

With Enterprise Server more than most products, understanding the core license metric is the precondition for everything else. A buyer that does not know which cores the authorization counts cannot tell whether a finding is fair, and will tend to concede the broadest reading by default. The defensive discipline is to read the metric definition first, establish which cores count and how virtualization and non production are treated, and then map the allocation against it. Most of the reduction available on an Enterprise Server core finding begins with knowing precisely what the metric is, because the count is only ever as large as the definition allows.

Related field notes

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

• how core based metrics inflate a Visual COBOL finding
• how sub capacity licensing applies to COBOL
• how COBOL virtualization affects core counting
• Enterprise Server high availability and core counts
• can OpenText count all cores against your COBOL license

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.