COBOL & Mainframe · Track 07

Mainframe ADLM metric definitions explained

Mainframe application development lifecycle tooling carries some of the least standardised metrics in the estate, and a finding takes full advantage of that ambiguity. Mainframe ADLM metric definitions matter because the same deployment can be counted by named users, by capacity, or by workload, and a finding tends to read whichever definition produces the largest number rather than the one the authorization sets.

The mainframe application development lifecycle management tools reached the OpenText estate through the Micro Focus acquisition that closed on January 31, 2023, and they are governed by the Additional License Authorizations rather than the OpenText EULA. ADLM tooling supports the development, testing, and management of mainframe applications across their lifecycle, and the products inside it can be licensed on different bases. That variety is exactly why definitions matter so much here. A buyer that does not know which metric governs each component cannot tell whether a finding has applied the right one, and a finding that is free to choose its definition will rarely choose the smaller count.

The metric families that appear in an ADLM finding

Mainframe ADLM findings draw on a few distinct metric families, and the first task is to know which one applies to each component. A named user metric counts the individuals authorised to use a tool, and is sensitive to all the proxy problems that inflate any seat count: stale accounts, service identities, and directory groups that no longer reflect reality. A capacity metric ties the license to processing capacity, usually cores, and behaves like the Enterprise Server core metric examined in what is an Enterprise Server core license metric. A workload metric ties the license to throughput, and carries the burst versus sustained ambiguity discussed in MIPS and workload metrics in an Enterprise Server audit. The danger is not any single metric but the freedom to mix them, applying a capacity reading to a component the authorization licenses by named user, or a workload peak to a tool licensed by capacity.

The mechanic

An ADLM finding is only as fair as the metric it applies to each component. The authorization assigns a metric to each tool. A finding that substitutes a larger metric for the one the agreement sets inflates the number before any count is even taken.

Where the definitions overreach

The overreach in a mainframe ADLM finding usually comes from a handful of definitional moves, each of which swaps the agreed basis for a more expensive one.

Named user counts built from access. Counting everyone with access rather than the authorised users who actually use the tool.
Capacity read at the host rather than the allocation. Counting all cores on a mainframe or distributed host rather than the capacity assigned to the ADLM workload.
Workload measured at peak. Treating a momentary throughput spike as the sustained level the license must cover.
Development and runtime conflated. Counting development tooling and runtime as if they shared a metric, when the authorization separates them, a distinction taken up in runtime versus development license counting for COBOL.
Distributed and mainframe treated alike. Applying a mainframe metric to a distributed deployment or the reverse, which the comparison in mainframe ADLM versus distributed COBOL licensing separates out.

Reading the definitions before conceding the count

The defense of a mainframe ADLM finding begins with the definitions and runs through the four Rs from there. Respond inside the seven day notice window and hold a single controlled channel, so each component is described once and the vendor cannot assemble a count from mismatched data. Reconstruct the effective position by reading the authorization for which metric governs each tool, then assembling the count under that metric: authorised users for named user tools, allocated capacity for capacity tools, sustained throughput for workload tools. Rebut the finding wherever it has substituted a larger metric, counted access as named users, read capacity at the host, or treated a peak as sustained. Resolve on terms that record the metric for each component, so the next audit starts from a settled basis rather than reopening the definitional question. How the vendor gathers its measurements in the first place is covered in how OpenText measures COBOL usage in an audit, and understanding that process helps anticipate where a definition will be stretched.

In a recent engagement

In a recent mainframe development tooling engagement, a finding applied a capacity metric across components that the authorization licensed by named user, producing a number far above the user population the buyer actually supported. Reading the authorization established which tools were genuinely capacity based and which were named user based, and reassembling the count under the correct metric for each removed a large block of the asserted shortfall. The buyer had been prepared to negotiate the capacity figure down. The larger reduction came not from negotiating the number but from establishing that the wrong metric had been used to produce it.

Definitions first, count second

Mainframe ADLM metric definitions reward buyers who refuse to discuss the count until the metric is settled. The tooling is varied, the metrics differ by component, and a finding that is free to choose its definition will inflate the number before a single user or core is counted. The defensive discipline is to read the authorization for the metric that governs each tool, build the count under that metric, and require the vendor to justify any departure from it. Most of the available reduction on a mainframe ADLM finding lives in the definitions, not in the arithmetic, because the arithmetic is only ever as fair as the definition it rests on.

Why the definitions are so easy to stretch

Part of what makes mainframe ADLM findings so prone to definitional overreach is that the tooling often sits across organisational boundaries. Development teams, operations groups, and testing functions all touch the lifecycle, and their access records live in different systems. A finding assembled from those scattered records tends to count the union of everyone who ever touched a tool, under whichever metric is most expansive. The remedy on a noncompliance finding is priced at then current list, with back maintenance and audit cost recovery stacked on top, so a definitional error at the base compounds through every layer above it. This is why establishing the correct metric for each component is not a technicality but the foundation of the whole defense.

Has an ADLM finding applied the wrong metric to your tooling?

We read the authorization for the metric that governs each component and rebuild the count under the correct basis before you respond. 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 metrics, capacity, and definitions. Each links back to the complete OpenText audit defense playbook for 2026.

If an OpenText or Micro Focus audit notice has arrived, the opening seven days matter more than any week that comes after. 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.