Enterprise Server high availability and core counts
High availability exists to keep a workload running, not to double the licence bill. Enterprise Server high availability and core counts collide when a finding counts standby and failover nodes as though they were active production capacity, charging twice for a design whose whole purpose is that only one node runs the workload at a time.
Visual COBOL and Enterprise Server are governed by the Additional License Authorizations, having reached the OpenText estate through the Micro Focus acquisition that closed on January 31, 2023. A high availability design places the COBOL workload behind redundant nodes so that if one fails another takes over, but in normal operation the workload runs on the active node while the standby waits idle. A discovery scan sees both nodes and their cores, and a finding can count all of them, even though the standby carries no running workload. This article sets out how standby and failover capacity should be treated and how to defend a finding that counts it as active.
Why high availability inflates a core count
The inflation is structural. A scan reports cores that exist, and a high availability cluster exists precisely to hold spare capacity in reserve. Counting the standby node's cores treats reserved capacity as consumed capacity, which is the same proxy error examined in what is an Enterprise Server core license metric, amplified by redundancy. A two node active and passive cluster scanned naively yields a count of double the workload's actual footprint, and a larger cluster multiplies the overstatement further. The defensive question is whether the standby node ever runs the COBOL workload in normal operation, and in a correctly configured failover design the answer is no.
How standby and failover capacity should be treated
The treatment of standby capacity depends on the entitlement language and the configuration, and several patterns recur.
- Cold standby. A node that is powered off or not running the software until a failover occurs, carrying no active consumption.
- Warm standby. A node ready to take over but not processing the workload in normal operation.
- Active and active. Both nodes sharing the workload, where the combined consumption is the relevant figure rather than the combined capacity.
- Disaster recovery. A separate site invoked only in a declared event, often addressed by specific entitlement provisions.
- Test failover. Failover exercises that fall within the non production scope in COBOL non production and test environment scope.
A standby node holds capacity in reserve; it does not consume it. A finding that counts active and standby cores alike charges twice for a design whose purpose is that only one node runs the workload. The question is which node runs the COBOL, not how many nodes exist.
The evidence that separates active from standby
Separating active capacity from reserved capacity is an evidence exercise, the same one set out in documenting COBOL runtime cores for a rebuttal. Cluster configuration shows which node is active and which is standby. Utilisation telemetry shows that the standby node carried no running COBOL workload during the audit period. Failover logs show whether and when a failover actually occurred. Together this evidence establishes that the standby capacity was reserved, not consumed, and that the finding's count of it describes hardware rather than usage. The reconstruction that organises this evidence is the one in reconciling COBOL entitlements before an audit.
The four Rs applied to redundant capacity
The defense follows the firm's four Rs. Respond inside the seven day notice window and preserve cluster and failover telemetry before it ages out. Reconstruct the active footprint by identifying which nodes ran the COBOL workload in normal operation and which held capacity in reserve. Rebut the finding line by line, removing standby and failover cores that the evidence shows carried no active workload, and reading the entitlement for any high availability provisions that govern the treatment. Resolve on terms that define how standby and disaster recovery capacity is counted, so a future audit cannot recount the same reserved nodes. The broader challenge this supports is the one in how to challenge a COBOL core measurement.
In a recent engagement
In a recent Enterprise Server engagement, a finding counted the cores of both nodes in an active and passive cluster, doubling the workload's footprint. Cluster configuration and utilisation telemetry showed the passive node had run no COBOL workload during the audit period and existed solely for failover. Once the standby cores were removed and the entitlement's high availability treatment was applied, the finding fell to the active node's actual consumption. 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.
Defending the design, not paying for it twice
The lesson is that redundancy is a resilience design, not extra consumption, and the licence position should reflect what runs rather than what waits in reserve. Because the noncompliance remedy is priced at then current list, with back maintenance and audit cost recovery stacked on top, counting a standby node as active multiplies a charge for capacity that never carried the workload. Establishing which node runs the COBOL, and resolving on terms that define standby treatment, is what keeps a high availability estate from being billed twice. To have an Enterprise Server finding tested against which nodes actually run your workload, open a case.
Reading the entitlement for high availability terms
Many entitlements address redundancy directly, granting rights for standby or disaster recovery capacity on terms distinct from active production. Before any evidence is even gathered, the authorizations should be read for these provisions, because a right that already covers a standby node makes the finding's count of it wrong on the face of the contract. Where the entitlement is silent, the consumption evidence carries the argument; where it speaks, the contract settles it before the telemetry is needed. A defense that reads the high availability terms first knows which battles the contract has already won and which require the utilisation record to decide. This ordering matters, because arguing consumption for a node the contract already exempts wastes effort the buyer could spend on the lines that genuinely turn on evidence.
Is your finding charging you twice for a failover design?
We separate active capacity from standby and disaster recovery reserve with cluster and utilisation evidence, and read the entitlement for high availability treatment. 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 capacity counting and the evidence that bounds it. Each links back to the complete OpenText audit defense playbook for 2026.
- what is an Enterprise Server core license metric
- documenting COBOL runtime cores for a rebuttal
- how COBOL virtualization affects core counting
- reconciling COBOL entitlements before an audit
- how to challenge a COBOL core measurement
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.