COBOL & Mainframe · Track 07

COBOL non production and test environment scope

Most COBOL estates run far more non production than production: development sandboxes, test environments, staging, disaster recovery, training. COBOL non production and test environment scope is the question of which of those instances are chargeable at all, because a finding that prices every environment as production multiplies the count by the number of lifecycle stages a buyer happens to maintain.

Visual COBOL and Enterprise Server are governed by the Additional License Authorizations rather than the OpenText EULA, having reached the OpenText estate through the Micro Focus acquisition that closed on January 31, 2023. Whether and how a non production environment is licensed is a question the authorization answers, and the answer is rarely that every environment is counted identically to production. A discovery scan, however, sees instances, not intentions: it cannot tell a production runtime from a test copy unless someone classifies them. When that classification is missing, the finding defaults to treating everything as production, which is the most expensive assumption available.

Why non production scope decides the count

The reason scope matters so much in a COBOL estate is structural. A single production application is typically shadowed by several non production environments that exist only to support it: one or more for development, one for test, perhaps one for staging and one for disaster recovery. If each of those is counted as a chargeable production deployment, the count for one application becomes the count for five. This is the same multiplication that drives the runtime overcount described in Enterprise Server runtime deployment counting, and it is why establishing scope is one of the highest leverage moves in a COBOL defense. The question is not how many instances exist but how many the authorization actually charges for.

The mechanic

Production is shadowed by non production. Count every environment as production and one application becomes many. The defense is to classify each environment by its role and hold each to the terms the authorization sets for that role, not to the production rate.

The environments that get miscounted

In practice the same non production environments show up priced as production in finding after finding, and naming them makes the scope review faster.

Development sandboxes. Environments where developers exercise code, which belong to the development metric rather than runtime, a distinction in Visual COBOL versus Enterprise Server licensing.
Test and QA environments. Instances used to validate releases, which the authorization may treat under non production rights covered in Enterprise Test Server and non production rights.
Disaster recovery and standby. Passive environments that serve no live traffic, examined for capacity in Enterprise Server high availability and core counts.
Training environments. Instances used only to teach, often counted as production simply because they are running.
Decommissioned copies. Old environments left on the inventory, covered in decommissioned COBOL workloads still on the audit.

Establishing scope under the four Rs

Scoping a COBOL estate correctly follows the four Rs. Respond inside the seven day notice window and ensure the inventory routed through the single controlled channel carries environment designations, not just hostnames, so that test is labelled test. Reconstruct the scope by classifying every instance as production or non production and, within non production, by its specific role, then reading the authorization for the rights that attach to each. Rebut the finding wherever it has priced a test, development, training, or disaster recovery environment as production. Resolve on terms that record the non production rights explicitly, so the next audit does not reopen the same scope. The classification is the work, and it is most effective done early, as part of the reconstruction described in reconciling COBOL entitlements before an audit.

In a recent engagement

In a recent COBOL engagement, an Enterprise Server finding counted a production application together with its development, test, and disaster recovery environments, pricing all four at production capacity. The opening number was, in effect, the production count multiplied by four. Classifying each environment by role, and applying the non production rights the authorization actually provided rather than the production rate, removed three of the four from the chargeable production count. The genuine production runtime remained; the environments that existed only to support it were scoped to their own terms. The reduction came from refusing to let the lifecycle around one application be billed as four applications.

Holding the scope through resolution

Establishing non production scope once is worth little if the resolution does not record it, because the next audit will start from the same undifferentiated inventory. The end state of a scope defense is an agreement that names the non production environments and the rights that attach to them, so the distinction survives into the forward position. Because the noncompliance remedy is priced at then current list, with back maintenance and audit cost recovery stacked on top, every environment wrongly scoped as production carries a multiplied charge, and every environment correctly scoped to non production removes that multiplication. Scope is therefore not housekeeping but one of the largest single levers in a COBOL finding. To have a COBOL estate scoped so that non production is held to its own terms, open a case.

Why scope is contested first

Scope is usually the first thing worth contesting in a COBOL finding because it is both high value and relatively clean to evidence. Environment designations, deployment records, and change history establish which instances are non production without requiring a deep argument about metrics. Settling scope early also simplifies everything that follows: once the non production environments are removed from the production count, the remaining core and runtime questions are asked of a much smaller and cleaner estate. A finding contested in the right order starts with scope, and the broader sequencing of a COBOL defense is set out in the complete OpenText audit defense playbook for 2026.

Has every COBOL environment been priced as production?

We classify each environment by role, apply the non production rights the authorization provides, and remove test, development, and DR from the production count. 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 environments, scope, and rights. Each links back to the complete OpenText audit defense playbook for 2026.

If an OpenText or Micro Focus audit notice has arrived, the first seven days carry more weight 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, cut 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.