Runtime versus development license counting for COBOL

A COBOL estate has two distinct kinds of license, one for the developers who write and compile code and one for the runtime that executes it in production, and a finding that blurs the line between them counts twice what the buyer actually deployed. Runtime versus development license counting for COBOL is one of the most common places a finding inflates, because the two metrics measure different things and the authorization governs each separately.

Visual COBOL and Enterprise Server reached the OpenText estate through the Micro Focus acquisition that closed on January 31, 2023, and are governed by the Additional License Authorizations rather than the OpenText EULA. The development side licenses the seats used to author and compile COBOL; the runtime side licenses the execution of the compiled application, often on a capacity metric like cores. When a finding counts development installs under a runtime metric, or runtime hosts as though each carried a development seat, it conflates two licenses that the agreement keeps apart, and the number climbs accordingly.

What each license actually covers

The development license covers the act of building software: the integrated development environment, the compiler, and the developer seat that uses them, whether in Visual COBOL for Eclipse, Visual Studio, or another environment. The runtime license covers the execution of the compiled application in production and is frequently measured on capacity rather than headcount. The two are priced and counted differently because they describe different uses. A developer seat does not become a runtime entitlement by virtue of the developer occasionally running the application, and a production runtime host does not require a development seat for every core it carries. The authorization sets out which is which, and reading it is what keeps the counts separate.

This distinction connects directly to Visual COBOL named developer versus runtime metrics, which works through how the named developer count and the runtime metric are measured against one another.

Where the conflation inflates the finding

Several patterns drive a COBOL finding above the defensible figure by mixing the two license types. Each is a line to separate and test against the authorization.

• Development installs counted as runtime. Treating a developer workstation that compiles code as though it executed production workload under a runtime capacity metric.
• Runtime hosts counted as development seats. Attaching a development seat to every production host where the runtime executes.
• Build and test environments miscategorised. Counting a build server or a continuous integration host as production runtime, a subject we develop in COBOL DevHub and build server license questions.
• Shared workstations double counted. Counting a machine that holds both development tools and a runtime under both metrics at once.

Reconstruct each count against the authorization

The four Rs apply cleanly. Respond inside the seven day notice window and hold a single controlled channel, so the development and runtime estates are described once and separately rather than scanned together and merged. Reconstruct the effective position by reading the authorization for how development seats and runtime capacity are each defined, then mapping the actual installs and execution to the correct metric. Rebut the finding line by line where it counts a development install as runtime or a runtime host as a development seat. Resolve on terms that fix the boundary between the two so the next audit does not blur it again. Building this separation before any vendor measurement runs is the high leverage move, and our note on how to scope COBOL development versus production sets out the practical steps.

In a recent engagement

In a recent COBOL engagement, a finding counted a set of developer workstations under the runtime capacity metric because the developers ran the application locally to test their changes. Reading the authorization established that local execution for development and test was a development activity, not production runtime, and the workstations fell out of the runtime count entirely. Separating the two licenses, install by install, removed a substantial block of the finding that rested entirely on the conflation.

Keep the two licenses apart

With COBOL more than most products, runtime versus development license counting decides whether a finding charges once or twice for the same estate. A buyer that lets the two metrics merge is paying for development seats on production hosts and runtime capacity on developer workstations. The defensive discipline is to read the authorization for how each license is defined, map every install and execution to the correct metric, and rebut every line that crosses the boundary. Most of the reduction available on a conflated COBOL finding comes from separating the development estate from the runtime estate and holding each to the metric the agreement assigns it.

Related field notes

These notes from the COBOL and Enterprise Server mainframe audit defense cluster cover development seats, runtime metrics, and scoping. Each links back to the complete OpenText audit defense playbook for 2026.

• Visual COBOL named developer versus runtime metrics
• how to scope COBOL development versus production
• Visual COBOL development seat counting traps
• COBOL DevHub and build server license questions
• how core based metrics inflate a Visual COBOL finding

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.