COBOL & Mainframe · Track 07

Defending an Enterprise Server core overclaim line by line

A core overclaim is not defeated with a single argument; it is dismantled one category of cores at a time. Defending an Enterprise Server core overclaim line by line means working through the count in a deliberate order, removing the cores the authorization does not support before settling on the figure the deployment genuinely requires.

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. A core overclaim arises when a finding counts more cores than the authorization makes countable, usually by reading the metric at the level of the physical host rather than the capacity allocated to the runtime. The number can look immovable because it is presented as a single total, but a core overclaim is always the sum of several distinct categories of cores. Separating those categories is what turns an intimidating total into a series of specific, answerable questions.

Start by fixing the metric, not the count

The first line of the defense is not a core at all; it is the definition. Before any core is added or removed, the authorization has to be read for what the metric counts: physical cores, allocated cores within a partition, or a sub capacity measure. Everything that follows depends on this, because a challenge to a specific core only makes sense once the basis for counting is settled. The grounding for this step is in what is an Enterprise Server core license metric, and the way a broad reading inflates the total is set out in how core based metrics inflate a Visual COBOL finding. With the metric fixed, the line by line work has a standard to measure each core against.

The mechanic

A core overclaim is a sum, not a single number. Fix the metric first, then remove each category of cores the authorization does not count. The total falls as each category is answered, and what remains is the defensible figure.

The order of challenges

A methodical rebuttal works through the categories of cores in an order that removes the largest and clearest overcounts first, then narrows to the marginal ones.

Cores outside the runtime partition. Physical cores on a host that the runtime never uses, removed by mapping the partition boundaries, as in how COBOL virtualization affects core counting.
Non production cores. Test, development, and disaster recovery capacity priced as production, separated under COBOL non production and test environment scope.
Standby and failover cores. Redundant capacity counted as active, which the analysis in Enterprise Server high availability and core counts addresses.
Decommissioned cores. Hosts retired before or during the audit period that remain in the inventory.
Cores covered by sub capacity terms. Capacity that the authorization counts at the allocation rather than the host.

The evidence each line needs

Each challenge stands or falls on evidence, and a rebuttal that asserts without documenting will not hold. Partition challenges need configuration records showing the boundaries within which the runtime executes. Non production challenges need an environment inventory that distinguishes production from test, development, and disaster recovery. Standby challenges need failover documentation showing that redundant capacity carries workload only on a node loss. Decommissioning challenges need retirement records dated against the audit period. Sub capacity challenges need the allocation records the authorization relies on. Assembling this evidence is the substance of the rebuttal, and documenting the runtime cores specifically is taken up in documenting COBOL runtime cores for a rebuttal. The discipline is to attach a category and a piece of evidence to every core the finding counts, so the vendor is answering a documented position rather than a general objection.

How the four Rs frame the rebuttal

The line by line work sits inside the larger method. 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 metric and mapping every core to a category. Rebut the finding category by category, removing cores outside the partition, non production capacity, standby nodes, decommissioned hosts, and capacity covered by sub capacity terms, each with its evidence attached. Resolve on terms that write the core definition and the agreed categories down, so the next audit starts from the settled figure rather than reopening the overclaim. The rebuttal is the third operation, but it is only as strong as the metric reading and the reconstruction that precede it.

In a recent engagement

In a recent Enterprise Server engagement, a core overclaim presented as a single large total. Working the count line by line, the defense removed the cores outside the runtime partitions first, then the disaster recovery hosts, then two standby nodes that carried no continuous workload, and finally a pair of decommissioned machines still listed in the export. Each removal was documented against configuration, environment, failover, and retirement records. By the time the categories were answered, the defensible core count was a fraction of the original total, and the remedy layered on top of it, back maintenance and audit cost recovery, fell in proportion. No single argument produced the result; the methodical removal of category after category did.

Dismantle the total, do not negotiate it

Defending an Enterprise Server core overclaim line by line works because a core total is never a single fact. It is an accumulation of cores from different categories, some defensible and many not, and a buyer who negotiates the total as one number leaves the indefensible categories inside it. The discipline is to fix the metric, sort every core into a category, attach evidence to each, and remove the categories the authorization does not support before discussing what remains. Most of the reduction available on a core overclaim comes from this sorting, not from haggling over the rate. To have a core overclaim worked through category by category, open a case.

Facing an Enterprise Server core overclaim presented as one number?

We fix the metric, sort every core into a category, attach evidence to each, and dismantle the overclaim line by line. 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 rebuttals, cores, and evidence. Each links back to the complete OpenText audit defense playbook for 2026.

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