COBOL & Mainframe · Track 07

Reducing a COBOL finding with workload evidence

A COBOL finding asserts a number; workload evidence answers it. Reducing a COBOL finding with workload evidence means moving the argument off the vendor's discovery scan and onto the data that shows what the COBOL estate actually runs, because runtime and transaction records describe consumption far more accurately than a hardware inventory ever can.

Visual COBOL and Enterprise Server are governed by the Additional License Authorizations rather than the OpenText EULA, having reached the OpenText estate through the Micro Focus acquisition that closed on January 31, 2023. The capacity metrics those authorizations define, cores and where relevant MIPS or workload measures examined in MIPS and workload metrics in an Enterprise Server audit, are meant to track real consumption. A discovery scan, by contrast, reports what hardware exists. The gap between what exists and what runs is precisely where a finding overstates, and workload evidence is the instrument that closes it.

Why workload evidence beats a hardware scan

The decisive advantage of workload evidence is that it describes the thing the metric is actually trying to measure. A core metric is a proxy for processing consumption, and transaction logs, runtime telemetry, batch schedules, and capacity reports show that consumption directly. When a finding counts the physical cores of a host, workload data can show that the COBOL on that host runs a few hours a day, on a fraction of the cores, serving a known and bounded transaction volume. That evidence does not merely dispute the finding; it replaces the proxy with the reality the proxy stands in for. This is the Rebut phase of the four Rs at its strongest, because it answers an assertion with measurement rather than with a competing assertion, building on the reconstruction in reconciling COBOL entitlements before an audit.

The mechanic

A scan reports capacity that exists. Workload evidence reports capacity that runs. The metric is a proxy for consumption, so the data that shows consumption directly outranks the data that merely shows hardware. Evidence replaces the proxy with the reality.

What counts as workload evidence

Workload evidence is whatever data demonstrates how much of the licensed capacity the COBOL estate actually uses, and several sources contribute.

Transaction and throughput logs. Records of how many transactions Enterprise Server processed, and over what period, relevant to the models in Enterprise Server transaction and MIPS models.
Runtime core utilisation. Hypervisor and operating system data showing the cores the workload actually consumed, the allocation question in how COBOL virtualization affects core counting.
Batch and schedule data. Evidence that a workload runs only in defined windows rather than continuously at full capacity.
Environment designations. Data confirming which workloads are production, tying to COBOL non production and test environment scope.
Decommissioning records. Evidence that a counted host carries no workload at all, covered in decommissioned COBOL workloads still on the audit.

Turning evidence into a reduction under the four Rs

Workload evidence reduces a finding when it is gathered early and applied systematically. Respond inside the seven day notice window and begin preserving runtime and transaction data before it ages out of retention. Reconstruct the consumption picture by assembling the evidence for each host and workload, so every counted item has a measured footprint behind it. Rebut the finding line by line, replacing the scanned capacity with the evidenced consumption wherever the two diverge. Resolve on terms that record the evidenced position, so the forward agreement reflects real usage rather than hardware. The structured assembly of this evidence for runtime cores specifically is the subject of documenting COBOL runtime cores for a rebuttal, and the broad challenge it supports is set out in how to challenge a COBOL core measurement.

In a recent engagement

In a recent COBOL engagement, an Enterprise Server finding rested entirely on a discovery scan of physical capacity. The defense assembled runtime utilisation data, batch schedules, and transaction logs showing that the workload ran in bounded windows on a fraction of the scanned cores. Set against the evidence, the finding's capacity number was shown to describe hardware the workload never fully used. The counted capacity was replaced, line by line, with the evidenced consumption, and the finding fell to the defensible figure. The reduction was characteristic of the firm's record across more than 200 defended audits, where workload evidence regularly carries a finding toward the 68 percent average reduction and contributes to the more than $90M in claims mitigated against vendor positions.

Holding the evidenced position

The value of workload evidence is realised only when the resolution is built on it. The end state is an agreement measured against evidenced consumption, with the supporting data retained, so a future audit that reverts to a hardware scan can be answered with the same evidence. Because the noncompliance remedy is priced at then current list, with back maintenance and audit cost recovery stacked on top, replacing scanned capacity with evidenced consumption removes a multiplied charge for capacity the buyer never used. Workload evidence is therefore not a supporting detail but often the decisive instrument in a COBOL defense, because it answers the vendor's strongest looking number, the scan, with something stronger still. To have a COBOL finding answered with the workload evidence that shows real consumption, open a case.

Why evidence is gathered early or not at all

The one constraint on workload evidence is time. Runtime telemetry, transaction logs, and utilisation data are often retained only for limited periods, and once they age out they cannot be reconstructed. A buyer who begins preserving this data inside the seven day notice window arrives at the rebuttal with the strongest possible answer; a buyer who waits may find the evidence gone. This is why the preparation work in preparing a COBOL entitlement reconstruction emphasises evidence retention, and why the whole sequence is set out in the complete OpenText audit defense playbook for 2026. Evidence gathered early is the difference between a finding answered with measurement and a finding answered with argument.

Is your COBOL finding built on a scan rather than your real workload?

We assemble the runtime, transaction, and utilisation evidence that shows real consumption, and replace scanned capacity with measured usage. 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 evidence, workload, and rebuttal. 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.