The COBOL compiler family: two editions, two cost models.

IBM Enterprise COBOL for z/OS is the current member of the long running IBM COBOL compiler family, the tooling that turns COBOL source into the load modules running across banking, insurance, and government batch and online systems. Many estates carry several generations at once: current Enterprise COBOL for active development, plus older compiler levels kept alive to rebuild legacy programs. The compiled programs themselves execute against the Language Environment runtime shipped inside z/OS, which is why the compiler entitlement and the run time entitlement are two separate questions that buyers often conflate.

Enterprise COBOL for z/OS is offered in two editions with genuinely different licensing models. The Monthly License Charge (MLC) edition bills as a recurring monthly charge on capacity in the conventional MLC way. The Value Unit Edition (VUE) is an IPLA program: a one time charge for an entitled license capacity, expressed in Value Units that convert from MSUs through a Value Unit Exhibit, followed by an annual Subscription and Support (S&S) charge. The two are not different products, they are different commercial wrappers around the same compiler, and the choice between them is a cost modeling decision, not a technical one.

The runtime row is the same in both columns on purpose: compiled COBOL runs against the Language Environment delivered with z/OS, so neither edition prices the execution of load modules. Both editions price the act of compiling.

The first cost driver is build footprint: the capacity on the systems where compiles actually run. Because production LPARs that only execute load modules do not need a compiler license, paying compiler cost across the whole estate rather than the build systems is the most common overspend. The second driver is edition choice, since the MLC and Value Unit wrappers price very differently over a multi year horizon. The third is version sprawl: estates that keep several compiler generations licensed to rebuild old programs carry support cost on each, and the question of whether every legacy level still needs an active entitlement is rarely asked at renewal.

The COBOL compiler audit usually turns on where the build happens versus where the entitlement sits. Common traps we see at pattern level:

The compiler bill responds to footprint and edition more than to raw capacity. The five levers that pay:

For an estate built on IBM Enterprise COBOL, the compiler is not casually swapped: compiled load modules, build pipelines, and language extensions are tied to it. Credible alternatives exist mainly at the edges. Third party COBOL development and modernization tooling can change where and how you build, and some modernization programs recompile COBOL into other environments entirely, but those are multi year projects, not renewal tactics. Within the IBM family, the real, low risk lever is footprint and edition, not a different compiler. Treat any pitch that promises a quick compiler replacement across a large legacy estate with caution.