Home › Articles › How much does a Visual COBOL core finding usually cost
COBOL & Mainframe · Track 07

How much does a Visual COBOL core finding usually cost

It is the first question every buyer asks when a Visual COBOL line appears in an audit, and it is the wrong number to fixate on. The opening figure on a Visual COBOL core finding is a function of how the metric is read, not a fixed price, and the same deployment can produce wildly different totals depending on which cores the count includes.

Visual COBOL 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. That distinction matters for cost, because the ALAs define the core metric, and the definition is where the dollar figure is actually set. A buyer who treats the opening number as the cost is conceding the broadest reading before the defense has even begun. The real question is not how much a Visual COBOL core finding costs, but how much of that finding is defensible once the metric is read against the deployment.

Why there is no single price

There is no published list figure that answers how much a Visual COBOL core finding usually costs, because the cost is built from three independent variables. The first is the core count the finding asserts, which can swing by an order of magnitude depending on whether it counts physical cores on the host, allocated cores in a partition, or a sub capacity measure. The second is the list price the vendor applies to those cores, since a noncompliance finding is priced at then current list rather than at whatever the buyer paid historically. The third is the remedy structure layered on top of the license charge. Change any one of these and the total moves, which is why two organisations running near identical Visual COBOL workloads can receive findings that differ by millions.

The single largest driver is almost always the core count, and that count is set by the metric definition. The mechanics of how a broad reading inflates the number are set out in how core based metrics inflate a Visual COBOL finding, and understanding the metric itself is covered in what is an Enterprise Server core license metric. Both apply directly to the question of cost, because a finding that counts the wrong cores produces a price that was never owed.

The mechanic

A Visual COBOL core finding does not have a fixed cost. It has an asserted cost, built from a core count, a list price, and a stacked remedy. The core count is the dominant variable, and the core count is set by the metric definition, not by the hardware.

What the remedy stacks into

The reason a core finding feels so large is that the noncompliance remedy does not stop at the price of the missing licenses. Under the terms that govern an OpenText audit, a licensee found short is deemed to have acquired the licenses at then current list price, must pay back maintenance and support for the period of the shortfall, owes first year maintenance on the newly deemed licenses, and reimburses the costs OpenText incurs in performing the audit. One core overcount therefore becomes four charges, each calculated off the same inflated base. This is why the opening number on a Visual COBOL finding so often lands far above what the buyer expected, and why reducing the core count reduces every layer above it at the same time.

Because each layer compounds the one beneath it, the leverage in a core finding sits at the bottom of the stack. Cut the asserted core count in half and the license charge, the back maintenance, and the first year maintenance all fall with it. The remedy structure that makes the opening number frightening is the same structure that rewards a disciplined reduction of the count.

What actually moves the number

The defensible cost of a Visual COBOL core finding emerges only after the metric has been read against the real deployment. A few questions decide most of the figure.

How the four Rs bring the cost down

The method that takes a Visual COBOL finding from its asserted figure to its defensible one runs through the same four operations applied across the estate. Respond inside the seven day notice window and route everything through a single controlled channel, so the deployment is described once and consistently. Reconstruct the effective position by reading the authorization for which cores the metric counts and mapping the actual allocation against it. Rebut the finding line by line where it counts physical cores, ignores partition boundaries, or prices non production hosts as production. Resolve on terms that write the core definition down, so the next audit does not reopen the same argument. Across more than 200 defended OpenText and Micro Focus audits, this approach has produced an average reduction of 68 percent in the initial compliance finding, and a core based product like Visual COBOL is precisely where that kind of reduction is available, because the count is so sensitive to the definition.

In a recent engagement

In a recent COBOL engagement, a finding priced every physical core across a consolidated server estate, then stacked back maintenance and audit cost recovery on top of that base. Reading the authorization established that the metric counted allocated cores within defined partitions, not the full physical inventory, and workload evidence showed the runtime confined to a fraction of the hosts. Holding the finding to the cores the workload actually used removed most of the asserted license charge, and because the remedy layers were calculated off that base, the back maintenance and first year maintenance fell in proportion. The cost the buyer ultimately settled bore little resemblance to the opening figure, and the difference came entirely from reading the metric rather than accepting it.

Ask what is defensible, not what is asserted

The honest answer to how much a Visual COBOL core finding usually costs is that the opening number is rarely the real one. The asserted figure reflects the broadest reading of the core metric, multiplied by list pricing, and stacked with back maintenance, first year maintenance, and audit cost recovery. The defensible figure reflects the cores the workload genuinely runs on, and it is almost always materially smaller. A buyer that anchors on the opening number negotiates against a figure that was never owed. The disciplined move is to read the metric first, establish which cores count, and let the cost follow from the deployment rather than from the finding.

Want to know what your Visual COBOL finding is actually worth?

We read the core metric, map it against the real deployment, and separate the asserted figure from the defensible one before you respond. To put 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 cost, cores, and metric definitions. 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 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.