Home › Articles › Visual COBOL named developer versus runtime metrics
COBOL & Mainframe · Track 07

Visual COBOL named developer versus runtime metrics

A single COBOL application is written by developers and then executed by a runtime, and those two activities are licensed by two different metrics. Visual COBOL named developer versus runtime metrics is the question of keeping the count of people who write code separate from the count of capacity that runs it, because a finding that blurs them charges the same work twice.

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. The named developer metric counts the people entitled to use the development tooling. The runtime metric counts the capacity on which compiled applications execute. These are different units measuring different things, and the authorization assigns each product to its own. When a finding loses the boundary, the danger is not just that one is counted on the wrong basis but that a single piece of software is counted under both, producing a number that exceeds anything the buyer actually consumes.

What each metric actually counts

The named developer metric is a headcount. It counts the developers authorised to use Visual COBOL, with all the sensitivities that attach to any per person count, including dormant accounts, shared logins, and people who have left, examined in Visual COBOL development seat counting traps. The runtime metric is a capacity measure. It counts the cores or equivalent on which Enterprise Server executes the compiled output, with the sensitivities set out in what is an Enterprise Server core license metric. The two are not interchangeable, and no amount of arithmetic converts a headcount into capacity or capacity into a headcount. A finding that treats them as fungible has made a category error before it has counted anything.

The mechanic

Developers are a headcount; runtime is a capacity. They measure different things and cannot be converted into one another. The double count appears when the same application is billed once by who wrote it and again by what runs it, as if those were two separate consumptions.

Where the two metrics get blurred

The blurring between named developer and runtime takes a few recurring forms, each of which puts the same work into two counts.

Separating the metrics under the four Rs

Keeping the two counts apart is a reconstruction exercise carried through the four Rs. Respond inside the seven day notice window and route the development and runtime inventories through the single controlled channel as distinct datasets, so neither is merged into the other. Reconstruct the position by counting the named developers under the developer metric and the runtime capacity under the capacity metric, with no item appearing in both. Rebut the finding wherever a developer install has been counted as runtime, a runtime host attributed to a developer, or a build server counted twice. Resolve on terms that record which metric governs which product, so a future audit cannot re merge them. The principle is the same as in any clean COBOL reconciliation, set out in reconciling COBOL entitlements before an audit: every component belongs to exactly one count.

In a recent engagement

In a recent COBOL engagement, a finding counted a team of developers under the named developer metric, which was correct, and then also counted their workstations as runtime deployments, which was not. The same development activity appeared in both the developer count and the runtime count, so each developer was effectively billed twice, once for the seat and once for an imaginary runtime. Separating the two, counting the developers under the developer metric and the genuine Enterprise Server hosts under the runtime metric, removed the duplicate runtime attribution entirely. The reduction came from insisting that a developer is counted as a developer and a runtime as a runtime, and that no person or machine sits in both columns.

One activity, one metric, one count

The discipline of Visual COBOL named developer versus runtime metrics reduces to a single rule applied without exception: every component of the estate is counted under exactly one metric, the one the authorization assigns to its product. Developers are counted as developers. Runtime capacity is counted as capacity. Build infrastructure is assigned to whichever the authorization specifies, and counted once. Because the noncompliance remedy is priced at then current list, with back maintenance and audit cost recovery stacked on top, a double count does not merely add a line; it multiplies a charge that should not exist at all. Holding the boundary between the two metrics is therefore one of the most direct protections against an inflated Visual COBOL finding. To have a COBOL estate counted with the developer and runtime metrics held strictly apart, open a case.

Why the double count is the costliest error

Among the errors that affect a Visual COBOL finding, the double count is the most costly because it inflates from both directions at once. A misclassification on a single metric overstates one count; a double count overstates two, and does so for the same underlying software. The buyer ends up charged for development it does perform and for runtime it does not, with the remedy stacked on top of both. Catching the double count therefore yields a larger reduction than correcting either metric in isolation, which is why separating the two is the first thing to establish in a Visual COBOL defense. The broader method that surrounds this work is set out in the complete OpenText audit defense playbook for 2026.

Has the same COBOL work been counted as both developers and runtime?

We hold the named developer and runtime metrics strictly apart, count each component once, and remove anything billed twice. 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 developer and runtime metrics. 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 weigh 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.