Having established in my previous blog what “COBOL runtimes” are, in this blog I’ll consider whether you should pay for COBOL runtime licenses – i.e. the right to ship and use COBOL runtime libraries with your applications.

After establishing what we should, or might, pay for, I’ll approach the subject of runtime charges by explaining some of the history of COBOL runtimes which established a model for COBOL runtime charges and then discuss what is a reasonable model today.

Assumption: We Pay for Added Value

Generally speaking we pay for goods and services that add value to our lives or company operations. If you don’t believe an item adds value you won’t pay for it – or will pay grudgingly if you are not given a choice which, for example, is how many people view taxes.

When you buy a COBOL compiler you expect it to compile your COBOL programs and give you code that will execute. If there was no COBOL runtime library, you would take that code and execute it on any computer that supported that code and would clearly need no license to do that. However, there is a COBOL runtime library that needs to be shipped, so does that add value worth paying for? Or is it a component that just supports your COBOL code so is only delivering the functionality you paid for when you purchased the COBOL compiler?

A look at COBOL runtime history will give us some insights into perceived value for COBOL runtimes through the years.

COBOL Runtime History

Space – The First Frontier

The issue of COBOL runtime licenses really surfaced with the advent of computers with microprocessors where it became possible to develop and compile programs on one computer but execute them on many other computers. The initial microcomputers, and later PCs, that were available from the mid ‘70s to the mid ‘80s didn’t have a lot of memory - 16KB was standard on the initial IBM PC introduced in 1981, with 640KB forming an upper bound for several years after that. It was a pretty challenging feat to execute COBOL programs in that amount of memory, particularly large applications that involved large data divisions and many modules. Creating a COBOL compiler wasn’t just a matter of turning the COBOL statements into executable code, the compiler vendors also had to provide the means of switching code in and out of memory as you couldn’t have everything in there at once. Thus the COBOL runtime wasn’t just providing subroutines to support the execution of COBOL statements, it was providing a virtual operating environment in which the compiled COBOL programs would execute.

Early COBOL vendors could therefore argue that when you used their COBOL runtime library on another computer you were using a specialized operating environment developed by them to allow your COBOL programs to execute. Without this environment your programs wouldn’t fit – the operating systems of those days wouldn’t be able to cope with the loads.

A reasonable case for added value.

 

Reaching Beyond COBOL

An ongoing challenge for COBOL compiler creators was (and is) that the COBOL standard (a generally accepted definition of COBOL) develops slowly but the wishes of those using COBOL compilers develop at least as quickly as their understanding of what is possible on the current operating platform (i.e. much faster than the standard). COBOL vendors would therefore add the ability to do things that went beyond standard COBOL. Some of the abilities were provided by extensions to the language, such as extensions to the DISPLAY statement to display data on a full screen rather than single lines being relayed to a terminal, and others were provided by adding subroutines to the COBOL runtime library – i.e. routines you invoked directly, and not just routines the compiler was invoking under the covers to support a COBOL statement.

Where the additional functionality was provided as additional subroutines, there was again a reasonable case for the COBOL runtime library adding value wherever it was installed.

 

Cross-Platform Environment

ISVs (Independent Software Vendors) create software to sell to others. For business applications many of them have chosen COBOL because it is supported across many different platforms. As long as they stick to a standard that is supported across platforms these software companies can write their applications once and deliver them on many different computers – a good business move as you can’t always determine which types of computer your potential customers will purchase.

Several COBOL vendors designed their compilers so that they generated an intermediate code that was not targeted at any particular machine. Their runtime libraries were actually runtime environments that created virtual computers that executed the intermediate code. Provided the vendor developed a runtime environment for a particular computer, you could compile your COBOL programs once and run the code on any of the supported computers.

Providing an execution environment was a reasonable added value.

Cash Cow for Vendors

Of course, any COBOL compiler vendor that has charged for use of its COBOL runtimes now has quite a nice cash flow as applications continue to be written and distributed that rely on those runtimes. This can be really nice for the vendors but painful to the customers if the perceived added value has diminished.

Today’s Perspective on Historical Added Value

Now that “micro computers” are no longer small, operating systems for those environments have advanced well beyond the additional capabilities offered by COBOL compiler vendors and the historical justifications for COBOL runtimes providing added value have weakened:

1. Memory management – fitting a lot into a small space
Today memory is plentiful and operating systems handle memory management well. It no longer makes sense for COBOL compiler vendors to insert their own layer of memory management on top of the operating system. Even if they do it is difficult to argue that they are providing added value.
2. Reaching beyond COBOL – providing additional abilities
While micro-processor operating systems were young there were many obvious functions that business programs needed and adding them to the COBOL environment was the only way a COBOL compiler vendor could make the functions available to their customers. With well-developed operating systems everything a user wants is provided and each new release provides abilities beyond what the user might have imagined. The task for COBOL (or other language) compilers is to make all operating-system-provided functions available as quickly as possible. The best way to do that is to get out of the way by providing direct access to operating system functions – for example by integrating well with the .NET Framework.
COBOL runtime libraries have little opportunity for providing added value.
3. Cross-Platform Environment
The need for a cross-platform environment is greatly reduced today compared to 10 or 20 years ago when there were many more possible target environments. It is quite viable for ISVs to target a single platform such as Windows because the market of Windows users is quite big enough for most companies’ ambitions. Also, performance expectations often mean that providing a virtual environment for executing intermediate code results in poorer performance than available with code that is compiled for a specific platform. Even if you create intermediate code your compiler vendor may provide you with an additional pre-execution step to change that code to the object code for the target platform. The runtime environment is no longer giving the added value of a portable virtual computer.

The Added Value Trap

Any company that saw the added value of the COBOL runtimes offered by a compiler vendor and chose to take advantage of that added value may now find themselves in a trap. The trap can work in two ways:

1. The added value has diminished or disappeared (as in the case of the COBOL runtime providing memory management) but the COBOL runtime charges remain. The functionality is available elsewhere free but there’s a sizeable cost in converting your applications to use that free model.
2. Whether or not the added value remains, the company has invested years of development effort in creating code that depends on the COBOL runtime environment. The cost of converting to another environment is so high that the compiler vendor can increase their COBOL runtime charges almost at will. Although the initial price of the runtime charge was considered a good investment for the added value provided, that is no longer the case.

Conclusion – Only Pay for COBOL Runtimes IF:
You HAVE to have the added value offered
AND are willing to deal with the added-value trap
OR are confident you have an iron-clad escape plan

Free Runtime Philosophy and Benefits

NetCOBOL compilers have been created with the following principles:

* Generate code that works seamlessly with the operating environment
* Give the programmer direct access to operating-system functions - do not insert run-time layers between the COBOL program and the operating system
* Only extend the COBOL language when required to make COBOL programs work seamlessly with the target environment (such as the .NET Framework)

Consequently the NetCOBOL runtime libraries are primarily there to support the compilation and execution of the COBOL syntax. This makes it easy for Alchemy Solutions to provide the runtime licenses for free and not place that additional financial burden on their NetCOBOL customers.

The compiler development philosophy also means that users of NetCOBOL compilers can usually take advantage of new functionality in the operating system as soon as it is available – they don’t have to wait for Fujitsu to develop COBOL-specific support for that functionality as can be the case if most operating system interactions have to go through a COBOL runtime layer.

If you think this philosophy makes sense, check out the NetCOBOL family of compilers or pick the brains of one of our reps who have a good understanding of most COBOL compiler-related issues and questions.