COBOL & Mainframe · Track 07

Enterprise Server runtime deployment counting

Enterprise Server is the runtime where compiled COBOL applications and transaction processing execute, and how its deployments are counted decides a large part of any COBOL finding. Enterprise Server runtime deployment counting goes wrong when every instance the vendor can see is treated as a chargeable production deployment, regardless of whether it is live, idle, redundant, or non production.

Enterprise Server reached the OpenText estate through the Micro Focus acquisition that closed on January 31, 2023, and like the rest of that estate it is governed by the Additional License Authorizations rather than the OpenText EULA. The authorization defines what a chargeable runtime deployment is and on what metric it is counted, usually capacity expressed in cores. An audit that counts deployments without reference to that definition counts instances rather than entitlement consumption, and instances are always more numerous than the deployments a buyer is actually obliged to license. The defensive task is to bring the count back to what the authorization charges for.

What counts as a runtime deployment

The first question in Enterprise Server runtime deployment counting is also the most important: what does the authorization treat as a deployment that consumes a license. The answer is narrower than the list of every place the software can be found running. A production runtime serving live transactions consumes entitlement. A passive standby that never serves traffic, a non production test instance, or a decommissioned host that was never removed from an inventory occupy different ground. The capacity question, expressed in cores, is examined in what is an Enterprise Server core license metric, but capacity is only counted once an instance is established as a chargeable runtime deployment in the first place. A finding that skips that establishing step and counts every instance equally has done the easy arithmetic and skipped the hard definition.

The mechanic

An instance is not the same as a chargeable deployment. Standby, test, idle, and decommissioned instances are visible to a scan but may not consume entitlement under the authorization. Counting instances rather than deployments is how a runtime finding inflates before any core is even measured.

Where the deployment count inflates

The inflation in an Enterprise Server runtime count tends to come from a small set of recurring sources, each of which adds instances that are not chargeable production deployments.

Standby and failover instances. High availability pairs counted as two production deployments when only one serves traffic, a question taken up in Enterprise Server high availability and core counts.
Non production environments. Test and development runtime instances priced as production, examined in COBOL non production and test environment scope.
Decommissioned hosts. Instances retired from service but never removed from the inventory the audit relied on, covered in decommissioned COBOL workloads still on the audit.
Virtualised capacity. A constrained instance counted on the full physical host rather than the capacity allocated to it, a problem set out in how COBOL virtualization affects core counting.

Counting deployments under the four Rs

Bringing the runtime count back to chargeable deployments follows the four Rs. Respond inside the seven day notice window and route the runtime inventory through a single controlled channel, so that instances are described with their role rather than dumped as an undifferentiated list. Reconstruct the deployment picture by classifying every instance as production, standby, non production, or decommissioned, and by establishing the capacity each chargeable deployment actually uses. Rebut the finding wherever it has counted a standby as production, a test instance as live, a retired host as active, or full physical capacity where the workload is constrained. Resolve on terms that record which instances are chargeable and on what capacity, so a future audit does not start the same overcount again. The classification work is the heart of it, and it is the same reconstruction discipline described in reconciling COBOL entitlements before an audit.

In a recent engagement

In a recent COBOL engagement, an Enterprise Server finding counted every runtime instance the discovery scan returned, including a warm standby that never served live transactions and two non production environments used only for testing. The opening count treated all of them as production deployments at full capacity. Classifying each instance by its actual role, and counting only the genuine production runtime at the capacity it used, removed the standby and the test environments from the production count entirely. The reduction came from establishing what each instance was for before agreeing it was a chargeable deployment, rather than accepting that visibility to a scan equalled consumption of a license.

Holding the count to real capacity

The discipline of Enterprise Server runtime deployment counting reduces to two questions asked of every instance in turn: is this a chargeable production deployment under the authorization, and if so, what capacity does it actually consume. An instance that fails the first question leaves the production count. An instance that passes is counted on its real capacity, not on the full physical host it happens to sit on. Asked consistently across the estate, those two questions separate the deployments a buyer must license from the instances that merely exist, and the gap between the two is usually where the opening finding lives. The remedy for a shortfall is priced at then current list, with back maintenance and audit cost recovery added on top, so every non chargeable instance removed from the production count removes a stacked charge, not just a line. To have an Enterprise Server runtime estate counted on chargeable deployments and real capacity, open a case.

Why the runtime count deserves its own scrutiny

Runtime is where the money is in a COBOL estate, because runtime is counted by capacity and capacity is the more expensive metric. That makes the runtime deployment count the single most consequential number in most COBOL findings, and the one most worth contesting line by line. A development seat overcount is bounded by the number of developers; a runtime deployment overcount is bounded only by how many instances a scan can find, which is a far larger and far softer number. Getting the runtime count right, by separating chargeable production deployments from everything else and counting each on its real capacity, is therefore not a detail but the core of an Enterprise Server defense. The broader method sits inside the complete OpenText audit defense playbook for 2026.

Has every Enterprise Server instance been counted as production?

We classify each runtime instance by role, separate chargeable deployments from standby, test, and decommissioned, and count each on real capacity. 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 runtime, capacity, and scope. Each links back to the complete OpenText audit defense playbook for 2026.

If an OpenText or Micro Focus audit notice has reached you, the opening 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, brought the average finding down 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.