How OpenText measures COBOL usage in an audit

The figure at the top of a COBOL finding is only as reliable as the measurement behind it, and that measurement is rarely as authoritative as it looks. Understanding how OpenText measures COBOL usage in an audit is the precondition for challenging a finding, because the scripts, scans, and records it relies on each carry assumptions that the buyer is entitled to test.

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. Under the terms that govern an audit, OpenText gives seven days notice and the right to copy relevant records, and the EULA places the responsibility for demonstrating compliance on the licensee. That allocation of responsibility is precisely why the measurement matters. A buyer who does not understand how the usage figure was produced cannot show where it is wrong, and a finding that goes unchallenged becomes the basis for a remedy priced at list, with back maintenance and audit cost recovery stacked on top.

What OpenText actually measures

A COBOL usage measurement is assembled from several sources, and each measures something slightly different from the thing the license actually counts. Discovery scans find where the software is installed, which is not the same as where it runs. Deployment inventories record hosts and environments, which may include non production and decommissioned systems. Core and capacity readings count the processors present on a host, which is not necessarily the capacity allocated to the COBOL runtime. Usage logs and license server records capture access events, which overstate the population of genuine users. None of these is wrong as a measurement; the problem is that each is a proxy for the licensed unit rather than the licensed unit itself, and a finding built from proxies counts more than the agreement supports.

The way a capacity reading inflates a core based finding is set out in how core based metrics inflate a Visual COBOL finding, and the records the vendor is entitled to copy are examined in what records does OpenText copy in a COBOL audit. Both help a buyer anticipate what the measurement will contain before it arrives.

Where the measurement overreaches

The gaps between what is measured and what is licensed are where a COBOL finding inflates, and they recur across engagements.

• Installed but not running. Discovery counts software present on hosts where the runtime never executes.
• Cores present but not allocated. Capacity readings count physical cores rather than the capacity assigned to the COBOL workload, the subject of how COBOL virtualization affects core counting.
• Non production counted as production. Test, development, and disaster recovery hosts swept into a production figure, addressed in COBOL non production and test environment scope.
• Access counted as use. License server logs and directory membership read as a developer or user population larger than the people who actually used the product.
• Retired systems still counted. Hosts decommissioned before or during the audit period remaining in the inventory.

Controlling the measurement on the buyer side

Because the licensee carries the burden of demonstrating compliance, controlling how the measurement is taken is part of the defense rather than an afterthought. The four Rs build that control in. Respond inside the seven day notice window and establish a single controlled channel, so that what reaches the vendor is scoped and accurate rather than a raw export that the vendor interprets. Reconstruct the effective position independently, before any vendor measurement script runs, by reading the authorization for what each metric counts and assembling the buyer's own evidence of runtime capacity and genuine use. Rebut the finding wherever its measurement counts installs as runtime, cores as allocation, access as use, or non production as production. Resolve on terms that record what was measured and how, so a future audit does not start from the same proxies. The aim is to ensure the measurement describes the deployment, not merely the footprint the tools happened to find.

In a recent engagement

In a recent COBOL engagement, the vendor measurement was a discovery export listing every host with the software installed, scored against a core count taken from the physical processors on each machine. Reconstructing the deployment independently showed that the runtime executed on a defined subset of hosts, within bounded partitions, and that several listed machines had been decommissioned during the period. Presenting the buyer's own evidence of where the runtime actually ran, rather than disputing the vendor's export line by line, shifted the basis of the finding to the real deployment. The reduction followed from controlling the measurement, not from arguing about the rate applied to it.

Test the measurement before you accept the number

How OpenText measures COBOL usage in an audit determines everything that follows, because the responsibility for demonstrating compliance sits with the licensee and the opening figure rests entirely on the measurement behind it. That measurement is a collection of proxies, installs, hosts, cores, and access events, each of which overstates the licensed unit it represents. The defensive discipline is to understand each proxy, reconstruct the deployment independently, and require the vendor to show that its measurement reflects runtime capacity and genuine use rather than mere presence. A buyer that tests the measurement rather than accepting it almost always finds room between what was counted and what was licensed. To have that measurement reconstructed independently, open a case.

Why timing the measurement matters

One reason buyers concede too much is that they let the vendor measurement run first and then argue against it. Reconstructing the deployment independently before any vendor script executes reverses that order. It means the buyer arrives at the discussion with its own evidence of runtime capacity and genuine use, rather than reacting to a figure it did not produce and does not fully understand. The seven day notice window is short, but it is enough to establish the single controlled channel and begin the independent reconstruction, and starting in that window is what keeps the measurement from being defined entirely by the vendor.

Related field notes

These notes from the COBOL and Enterprise Server mainframe audit defense cluster cover measurement, records, and scope. Each links back to the complete OpenText audit defense playbook for 2026.

• how core based metrics inflate a Visual COBOL finding
• what records does OpenText copy in a COBOL audit
• how COBOL virtualization affects core counting
• COBOL non production and test environment scope
• reducing a COBOL finding with workload evidence

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.