COBOL & Mainframe · Track 07

Defending COBOL against an inflated core baseline

Every COBOL finding starts from a baseline, and if the baseline is wrong, everything built on top of it is wrong by the same factor. Defending COBOL against an inflated core baseline means challenging the starting core count the finding rests on, because a baseline that counts more cores than the workload ever ran on multiplies the entire claim before a single rate is applied.

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. A core based finding is only as sound as the baseline core count it begins with, and that baseline is assembled from a discovery scan that sees hardware, not entitlement, and physical capacity, not actual workload. When the baseline counts every core on every host it can reach, the finding inherits that inflation and carries it through every subsequent calculation. This article sets out how the baseline inflates, why it matters more than any later step, and how the defensible core baseline is rebuilt line by line.

What the core baseline is

The baseline is the starting core count the finding treats as consumed by COBOL, before any rate, edition, or remedy is applied. It is the foundation of the whole claim, and the rate only has meaning against it. The way that baseline is supposed to be derived is set out in what is an Enterprise Server core license metric, and the mechanism by which it inflates is the subject of how core based metrics inflate a Visual COBOL finding. Because every later figure scales with the baseline, an inflated baseline is the single most consequential error in a core based finding.

Where the baseline inflates

The inflation enters at the start, when the scan reads hosts and the baseline counts everything visible. Several patterns recur when defending COBOL against an inflated core baseline.

Full host capacity as the baseline. Every physical core counted when the workload ran on a partition, which is corrected through how sub capacity licensing applies to COBOL.
Non production folded into the baseline. Test and standby cores counted alongside production cores at the same starting point.
Decommissioned hosts still counted. Retired systems left in the baseline, tying to decommissioned COBOL workloads still on the audit.
High availability nodes double counted. Standby cluster nodes counted as active, inflating the baseline before any rate applies.

The mechanic

The baseline sets the scale of the whole finding, and every later figure is a multiple of it. An inflated baseline is not a small error at the start, it is a large error carried through every subsequent line, and it is corrected by rebuilding the baseline from the cores the workload actually ran on rather than from everything the scan could see.

Rebuilding the baseline under the four Rs

The defense rebuilds the baseline through the firm's four Rs. Respond inside the seven day notice window, set a single controlled channel, and prevent any vendor script from establishing a baseline before the estate is scoped. Reconstruct the position by reading the Additional License Authorizations and building an independent core count from production workload, allocated capacity, and entitled deployments, rather than from raw host inventory. Rebut the finding line by line, removing every core that belongs to a decommissioned host, a non production environment, a standby node, or a constraint the baseline ignored. Resolve on terms that record the agreed baseline, so a future audit starts from the defensible count rather than the inflated one. The reconciliation that organises this work is the one in reconciling COBOL entitlements before an audit.

Why the baseline is worth fighting first

Because the noncompliance remedy is priced at then current list, with back maintenance and audit cost recovery stacked on top, an error in the baseline is multiplied three ways before the buyer sees the total. Correcting a rate saves a fraction, but correcting the baseline saves a proportion of the entire claim, which is why the baseline is the first thing the defense attacks. The evidence that supports a corrected baseline is the workload record discussed in reducing a COBOL finding with workload evidence, and assembling it early, before the vendor fixes a baseline of its own, is what gives the correction its force.

In a recent engagement

In a recent COBOL engagement, a finding built its baseline from full host capacity across an estate that included partitioned production, non production test instances, and decommissioned hosts that were still in the inventory. The defense read the authorizations, rebuilt the baseline from production workload and allocated capacity, and removed the retired, non production, and standby cores the original baseline had folded in. Once the baseline reflected the cores the workload actually ran on, every figure that scaled from it fell with it, and the finding came down 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 baseline is decided by workload, not inventory

The lesson is that the baseline is the cores the workload actually ran on, established by entitlement and evidence, not the cores a scan could reach. Because the remedy multiplies any baseline error three ways, rebuilding the baseline is the most valuable single step in defending a core based COBOL finding. Reading the authorizations, rebuilding the baseline from workload, and resolving on terms that record the agreed count is what keeps the finding anchored to reality rather than to inventory. This discipline is the foundation for the broader work in how to challenge a COBOL core measurement. To have a COBOL finding tested against a baseline rebuilt from actual workload, open a case.

Is your finding built on a baseline that counts every core in sight?

We read the Additional License Authorizations, rebuild the core baseline from production workload and allocated capacity, and remove every core that belongs to a retired, non production, or standby system. 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 the core metric, the inflation mechanism, and the evidence that rebuilds a baseline. 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 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.