COBOL & Mainframe · Track 07

Visual COBOL for Eclipse and Visual Studio seats

Visual COBOL ships inside familiar developer tools, and that is exactly where the seat count blurs. Visual COBOL for Eclipse and Visual Studio seats are counted by who is licensed to develop, but a finding often counts who has the IDE installed, and the gap between an installed plugin and an active developer is where the overclaim lives.

Visual COBOL integrates into the Eclipse and Visual Studio development environments, and it reached the OpenText estate through the Micro Focus acquisition that closed on January 31, 2023, governed by the Additional License Authorizations. The development seat is a named or assigned unit tied to a person who develops COBOL, not to every machine where the tooling happens to be present. Because Eclipse and Visual Studio are widely deployed for many languages, a discovery scan that keys on the presence of the IDE, or even on the Visual COBOL extension, can count installations that no COBOL developer ever uses. This article sets out where that overclaim arises and how the real seat count is established.

What a development seat actually licenses

A Visual COBOL development seat licenses a developer to author, compile, and debug COBOL within the IDE. The unit is the developer, and the entitlement is consumed when a person is assigned to develop. It is not consumed by the mere existence of the extension on a workstation, nor by a user who has Visual Studio installed for other purposes and never opens a COBOL project. This is the same named against active distinction examined in Visual COBOL named developer versus runtime metrics, and it is the distinction a finding most often collapses.

Where the IDE based overclaim arises

The overclaim arises because the signal a scan can see is presence, not use. Several patterns inflate the count.

Bundled installs. Visual COBOL deployed by an image or package to machines that never develop COBOL.
Dormant extensions. The Eclipse or Visual Studio extension present but never opened against a COBOL project.
Shared workstations. One machine counted as several seats, or several machines for one developer counted separately.
Departed developers. Seats still showing for people who have left or moved off COBOL work.
Build agents. Automated build tooling counted as developer seats, a question that overlaps with COBOL DevHub and build server license questions.

The mechanic

A development seat is a person who develops COBOL. A scan sees an installed IDE or extension. The two are not the same, and the count of installations is almost always larger than the count of developers. The seat count is set by active development, not by presence.

Establishing the real seat count

The real seat count is established by mapping installations to active development, the same exercise that defends a seat overclaim anywhere in the estate. Usage telemetry, project access records, source control activity, and personnel data together show which installations correspond to people who actually author COBOL. Each dormant install, each departed developer, and each build agent miscounted as a seat is removed from the count. What remains is the defensible number of developers, which is the number the entitlement is meant to measure. This evidence based approach mirrors the workload evidence logic in runtime versus development license counting for COBOL, applied to people rather than to capacity.

The four Rs applied to developer seats

The defense follows the firm's four Rs. Respond inside the seven day notice window and preserve IDE usage and source control telemetry before it ages out. Reconstruct the developer population by mapping every counted installation to evidence of active COBOL development. Rebut the finding line by line, removing dormant installs, shared workstation duplicates, departed developers, and build agents that are not developer seats. Resolve on terms that define the seat as an active developer and set a clear basis for counting, so a future audit cannot revert to counting installations. The line by line discipline is the one set out in how to challenge a COBOL core measurement, applied here to seats rather than cores.

In a recent engagement

In a recent Visual COBOL engagement, a finding counted every workstation carrying the Visual Studio extension as a development seat. Usage telemetry showed that a large share of those installations had never opened a COBOL project, and several belonged to developers who had moved off COBOL entirely. Once installations were mapped to active development and the dormant and departed entries were removed, the defensible seat count was far below the finding. The reduction echoed the seat overclaim pattern recorded in case file E-02, where mapping actual users rather than installations carried a developer seat finding down sharply, consistent with the firm's 68 percent average reduction across more than 200 defended audits.

Counting developers, not installations

The lesson is that a developer seat is owed for a developer, and the only reliable way to count developers is to look at who develops. Because the noncompliance remedy is priced at then current list, with back maintenance and audit cost recovery stacked on top, every dormant installation counted as a seat multiplies a charge for a developer who does not exist. Mapping installations to active development, and resolving on a definition that holds, is what keeps the seat count honest. To have a Visual COBOL seat finding tested against your real developer population, open a case.

Why an installation count is not an entitlement gap

It is worth stating plainly that a count of installations exceeding a seat entitlement is not, by itself, evidence of a shortfall. Software is widely imaged and packaged, and the presence of a tool says nothing about whether a person uses it to develop COBOL. A finding that treats installation count as consumption has mistaken a deployment artefact for a licensed activity. The buyer is entitled to be measured on what the entitlement actually counts, which is developers, and the burden of showing active development falls on the evidence rather than on the raw install list. Drawing that line early prevents an installation inventory from becoming the default basis of the finding, and it reframes the conversation around the question the seat metric was written to answer: how many people actually develop COBOL in this estate.

Is your Visual COBOL finding counting IDE installs instead of developers?

We map every counted installation to evidence of active COBOL development and remove dormant, duplicated, and departed seats. 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 developer seats and the active use that defines them. 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 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.