COBOL & Mainframe · Track 07

Documenting COBOL runtime cores for a rebuttal

A rebuttal is only as strong as the evidence behind it. Documenting COBOL runtime cores for a rebuttal means assembling the runtime, utilisation, and allocation data that shows how many cores the COBOL workload actually consumed, so a scanned capacity figure can be replaced with measured consumption line by line.

Visual COBOL and Enterprise Server are governed by the Additional License Authorizations, having reached the OpenText estate through the Micro Focus acquisition that closed on January 31, 2023. A core metric is a proxy for processing consumption, and a discovery scan reports the cores a host contains rather than the cores the COBOL on it uses. The rebuttal that takes a core finding down is the one that documents the difference. This article sets out what runtime core documentation consists of, how to gather it before it ages out, and how it is presented so that a finding cannot ignore it.

Why documentation, not assertion, moves a core finding

A finding asserts a core count drawn from a scan. An unsupported objection meets that assertion with another assertion, and the larger number tends to prevail. Documented runtime evidence breaks the symmetry: it answers the proxy with the consumption the proxy stands in for, and consumption data outranks capacity data because it measures the thing the metric is meant to capture. This is the Rebut phase of the four Rs at its strongest, and it is the same logic set out in reducing a COBOL finding with workload evidence, narrowed here to the specific task of documenting cores.

What runtime core documentation contains

Documenting runtime cores means collecting the data that shows actual consumption for each counted host or workload.

Hypervisor allocation records. The cores assigned to the COBOL workload, distinct from the host total, the question in how COBOL virtualization affects core counting.
Operating system utilisation logs. Sustained core usage over the audit period rather than a single peak.
Batch and schedule records. Evidence that a workload runs only in defined windows, not continuously at full capacity.
Affinity and pinning configuration. Settings that bound the COBOL workload to a subset of cores.
Environment labels. Designations separating production from the test scope in COBOL non production and test environment scope.

The mechanic

A scan documents cores that exist. A rebuttal documents cores that ran. For each counted host, the evidence pairs the scanned figure with the measured consumption, and the finding is reduced to the measured figure wherever the two diverge. Documentation turns an objection into proof.

Gathering the evidence before it ages out

The constraint on runtime documentation is retention. Utilisation logs, hypervisor telemetry, and schedule data are often kept only for limited periods, and once they age out they cannot be recreated. A buyer who begins preserving this data inside the seven day notice window arrives at the rebuttal with a complete record; a buyer who waits may find gaps that weaken otherwise strong arguments. This is why the preparation work in preparing a COBOL entitlement reconstruction places evidence retention first, and why the Respond phase of the method moves immediately to preservation.

Presenting the documentation in a rebuttal

Documentation persuades when it is organised so the finding cannot sidestep it. For each line in the finding, the rebuttal pairs the scanned core count with the documented consumption and states the variance plainly. The presentation follows the structure used in defending an Enterprise Server core overclaim line by line: every counted item is addressed individually, with its evidence attached, so the reduction is the sum of many small, documented corrections rather than a single sweeping objection. A finding answered this way has nowhere to retreat, because each line has already been met with measurement.

In a recent engagement

In a recent engagement, an Enterprise Server finding counted the full core complement of several virtualisation hosts. The defense documented hypervisor allocation, sustained utilisation, and batch schedules for each host, pairing every scanned figure with the cores the COBOL actually consumed. The documentation showed that the workload ran in bounded windows on a fraction of the allocated cores, and the finding was reduced line by line to the documented consumption. 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.

Documentation as the durable defense

The lasting value of runtime documentation is that it survives the engagement. Retained alongside the resolution, the same evidence answers a future audit that reverts to a scan, so the buyer never relitigates the same cores. Because the noncompliance remedy is priced at then current list, with back maintenance and audit cost recovery stacked on top, replacing scanned capacity with documented consumption removes a multiplied charge for cores the workload never used. Documentation is therefore not paperwork but the instrument that makes a rebuttal hold. To have your COBOL runtime cores documented and a core finding answered with measured consumption, open a case.

Pairing each line with its evidence

The presentation that persuades is one where no counted line stands without its answer. For every host the finding names, the rebuttal attaches the allocation record, the utilisation log, and the schedule data that together describe what the COBOL actually consumed, and it states the variance between the scanned figure and the measured one in plain terms. Organised this way, the finding cannot retreat to a general claim about capacity, because each specific line has already been met with specific evidence. The reduction becomes the arithmetic sum of many documented corrections, each one defensible on its own, which is far harder to dispute than a single sweeping objection to the total.

This is also why documentation is gathered host by host rather than in aggregate. An average utilisation figure across an estate can be argued away; a host by host record cannot, because it answers the finding in the same units and at the same granularity the finding used to assert it. The rebuttal meets the scan where it lives.

Is your core finding waiting for evidence you have not preserved yet?

We assemble hypervisor, utilisation, and schedule documentation for every counted host and pair it line by line with the scanned figure. 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, virtualisation, and line by line 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.