Mainframe ADLM versus distributed COBOL licensing

The same COBOL can be licensed two very different ways depending on where it runs. Mainframe ADLM versus distributed COBOL licensing is the distinction between the application development and lifecycle model used in mainframe contexts and the seat and capacity model used for distributed Visual COBOL and Enterprise Server, and a finding that applies one model's metrics to the other estate overstates the position.

Visual COBOL, Enterprise Server, and the mainframe application development lifecycle management tooling reached the OpenText estate through the Micro Focus acquisition that closed on January 31, 2023, and all are governed by the Additional License Authorizations. But within those authorizations the mainframe ADLM context and the distributed COBOL context are measured differently, because the workloads, the deployment models, and the development practices differ. This article sets out how the two models diverge, where a finding conflates them, and how the right metric is restored for each part of the estate.

What mainframe ADLM measures

The mainframe application development lifecycle management model addresses development against and for the mainframe, and its metrics are defined for that context. The unit definitions, examined in mainframe ADLM metric definitions explained, reflect mainframe development practice rather than distributed seat counting. A finding that imports a distributed seat metric into the ADLM context, or that counts ADLM activity as though it were distributed Enterprise Server runtime capacity, misapplies the model. The entitlement language settles which metric governs, and reading it for the ADLM estate specifically is the first step in scoping the finding correctly.

What distributed COBOL measures

Distributed COBOL, meaning Visual COBOL development on Eclipse and Visual Studio and Enterprise Server runtime on distributed hosts, is measured on the seat and capacity models discussed across this cluster. Development is counted in developer seats, as in Visual COBOL named developer versus runtime metrics, and runtime is counted on cores or workload, as in what is an Enterprise Server core license metric. These metrics assume distributed infrastructure and distributed development tooling, and they do not transfer cleanly to a mainframe context any more than mainframe metrics transfer to distributed hosts.

Where a finding conflates the two models

The conflation arises when a discovery scan flattens the estate and a finding counts everything by one rule. Several patterns recur.

• One metric across both estates. A capacity figure applied uniformly when part of the estate is governed by ADLM definitions.
• Double counting at the boundary. A workload that bridges mainframe and distributed counted under both models at once.
• Seat and capacity overlap. Development activity counted as both an ADLM unit and a distributed seat.
• Misplaced environments. Mainframe test or development activity counted as distributed production, tying to COBOL non production and test environment scope.

Restoring the right model under the four Rs

The defense matches each part of the estate to its model through the firm's four Rs. Respond inside the seven day notice window, establish a single controlled channel, and prevent any vendor script from measuring before the models are scoped. Reconstruct the position by reading the Additional License Authorizations to establish which estate is governed by ADLM definitions and which by distributed seat and capacity metrics, then label every item accordingly. Rebut the finding line by line, removing any line that applies the wrong model and any line that counts a boundary workload twice. Resolve on terms that record which model governs which estate, so a future audit cannot reconflate them. The reconciliation that organises this is the one in reconciling COBOL entitlements before an audit.

In a recent engagement

In a recent COBOL engagement, a finding applied a single distributed capacity metric across an estate that included mainframe ADLM governed activity, counting the latter on a rule it was never entitled under. The defense read the authorizations, separated the ADLM estate from the distributed estate, and showed that a boundary workload had been counted under both models. Once each part was matched to its governing model and the double counted boundary line was removed, the finding fell to the defensible figure for each estate. 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.

Matching the estate to the model

The lesson is that the model is decided by the entitlement and the estate, not by a scan that sees only COBOL. Because the noncompliance remedy is priced at then current list, with back maintenance and audit cost recovery stacked on top, applying the wrong model multiplies a charge under a rule the buyer never agreed to for that estate. Reading the authorizations, scoping each estate to its model, and resolving on terms that hold the boundary is what keeps mainframe and distributed COBOL measured by their own rules. To have a COBOL finding tested against the model that actually governs each part of your estate, open a case.

Why the boundary workload deserves special care

The workloads that bridge mainframe and distributed estates are where double counting is most likely and hardest to spot, because they appear legitimately in both views. A process that develops for the mainframe using distributed tooling, or a workload that spans both environments, can be counted once under ADLM definitions and again under distributed metrics without either count looking wrong in isolation. Identifying these boundary workloads explicitly, and deciding which single model governs each, is the step that prevents a finding from charging twice for one activity. The reconciliation treats every boundary item as a deliberate decision rather than letting it fall under both models by default, because the default in a flattened scan is always the more expensive reading, and only a deliberate scoping decision corrects it.

Related field notes

These notes from the COBOL and Enterprise Server mainframe audit defense cluster cover the ADLM and distributed models and the metrics each defines. Each links back to the complete OpenText audit defense playbook for 2026.

• mainframe ADLM metric definitions explained
• Visual COBOL named developer versus runtime metrics
• what is an Enterprise Server core license metric
• reconciling COBOL entitlements before an audit
• COBOL non production and test environment scope

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.