Enterprise Server PAC and region licensing
Enterprise Server deployments are built from regions and clusters, not from single processes, and a finding that misreads that topology can count the same capacity several times. Enterprise Server PAC and region licensing turns on how a Performance and Availability Cluster and its regions map to the licensed metric, because a finding often treats every region and every cluster node as separately countable when the authorization counts the underlying capacity once.
Enterprise Server 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 architecture is deliberately layered. A Performance and Availability Cluster, or PAC, groups multiple Enterprise Server instances so that regions can share workload and survive the loss of a node. Each region is a runtime instance that hosts COBOL applications and transaction processing. That layering is excellent for resilience and throughput, and it is also where a finding finds room to inflate, because each layer presents a number that a broad reading can count on its own.
How clusters and regions relate to the metric
The licensed metric for Enterprise Server is commonly tied to processing capacity, usually cores, rather than to the number of regions or cluster members. That distinction is the heart of PAC and region licensing. A region is a logical construct that runs on capacity already present on a host, and a PAC coordinates regions across hosts that the buyer has, in principle, already accounted for under the core metric. When a finding counts each region as a separate licensable unit, or treats every node in a cluster as if it carried an independent entitlement obligation, it is counting the topology rather than the capacity, and the topology can multiply quickly. A single PAC with several regions across a handful of nodes can be made to look like many times its actual licensable footprint.
The relationship between capacity and the count is set out in what is an Enterprise Server core license metric, and the way deployments are tallied is examined in Enterprise Server runtime deployment counting. Both make the point that the licensable figure follows the capacity definition, not the number of logical instances running on it.
A PAC and its regions run on capacity the core metric already measures. Counting each region or cluster node as a separate licensable unit double counts capacity that the authorization counts once.
Where a PAC and region finding double counts
The double counting in a clustered Enterprise Server estate tends to come from a small number of recurring sources, each rooted in counting logical units rather than capacity.
- Regions counted as licenses. Multiple regions on one host counted as multiple entitlements, when they share the host capacity the metric already measures.
- Cluster nodes counted independently. Each PAC member counted in full, including nodes that exist for failover rather than for additional throughput, a question that overlaps with Enterprise Server high availability and core counts.
- Standby capacity priced as active. Redundant capacity that carries workload only on failure counted as if it ran the workload continuously.
- Throughput conflated with deployment. Transaction or workload figures from a busy region read as evidence of additional licensable capacity, which the workload metrics discussion in MIPS and workload metrics in an Enterprise Server audit addresses directly.
Holding a clustered deployment to its real footprint
Untangling a PAC and region finding is a methodical exercise that the four Rs are built to carry. Respond inside the seven day notice window and route everything through a single controlled channel, so the cluster topology is described once and accurately rather than reconstructed by the vendor from partial data. Reconstruct the effective position by reading the authorization for what the metric counts, then mapping the PAC, its regions, and the capacity each runs on, separating active capacity from failover and standby. Rebut the finding wherever it counts regions or nodes as independent entitlements, prices standby capacity as active, or reads throughput as additional deployment. Resolve on terms that record how clusters and regions map to the metric, so a future audit cannot recount the same topology. The aim throughout is to make the finding describe capacity, which is what the agreement licenses, rather than the count of logical instances, which is merely how the buyer chose to arrange that capacity.
In a recent engagement
In a recent Enterprise Server engagement, a finding counted every region across a multi node PAC as a separate licensable unit, producing a figure several times the licensable capacity. Mapping the cluster established that the regions ran on a defined set of cores already measured by the metric, and that two of the nodes existed purely for failover and carried no continuous workload. Reading the authorization confirmed that the metric counted capacity rather than logical instances. Holding the finding to the active capacity, and excluding the standby nodes and the duplicate region counts, reduced the number to the deployment the buyer actually ran. The reduction came from describing the topology correctly, not from disputing the rate.
License the capacity, not the cluster diagram
Enterprise Server PAC and region licensing rewards buyers who insist that the count follow capacity rather than topology. A clustered deployment is designed to spread regions across nodes for resilience and performance, and that same design gives a finding several numbers to choose from when only one, the licensable capacity, reflects what the agreement covers. The defensive discipline is to read the metric, map the cluster and its regions to the capacity they run on, separate active from standby, and require the vendor to justify any count above the licensable capacity. A buyer that does this does not pay for its own resilience architecture twice. If you want a clustered Enterprise Server deployment mapped before you respond, open a case and we will start with the topology.
Is a finding counting every region and node in your PAC?
We map the cluster, separate active capacity from failover, and hold an Enterprise Server finding to the capacity the authorization actually counts. 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 clusters, regions, and capacity. Each links back to the complete OpenText audit defense playbook for 2026.
- Enterprise Server runtime deployment counting
- what is an Enterprise Server core license metric
- Enterprise Server high availability and core counts
- Enterprise Server transaction and MIPS models
- MIPS and workload metrics in an Enterprise Server audit
If an OpenText or Micro Focus audit notice has landed, 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.