Contributed by: remy Tuesday, 19 April 2016, 10:25 @ CEST
Cobol is mainly used in a business environment where architectures use the IPO principle: Input some data (records in a file), process them and output them (print records). Off course, this is a very simplistic view.
This IPO principle is still found in most modern system architectures and is sometimes synonimized with client-server architecture. Fact is that input forms got smart as http-requests, and printed reports went also intelligent in the form of html-pages. From a Cobol perspective these smart entities are a foreign concept since they are in free format.
And we want Cobol to interface with these smart entities, don't we? While Cobol is based on fixed length data, it looks like mission impossible to introduce variable-length string manipulation needed for interfacing with current software protocols, like http and https.
The Internet and its protocols, however, offers exactly this (IPO) environment when you visually think of the webserver as the operating system.
So, having the requirement to run Cobol software on the web implies the ability to read a external form, process its data and print some report that is rendered externally. Some compilers have implemented such interface with ACCEPT and DISPLAY (as opposed to READ and WRITE). The references to the external entities are implemented using the long-known CGI interface (http-requests with GET and POST) and generating html-pages from templates.
Which summarizes the problem statement:
In order to solve this problem, we could use a library for CGI and a library for a template engine. The implementation effort is reduced to interfacing with these libraries. We will see that this is impossible in pure Cobol, but made easy when the compiler talks C and by developing a few wrappers.
Reference, quoted from [Acucobol GT reference manual](http://documentation.microfocus.com/help/topic/com.microfocus.eclipse.infocenter.extendACUSuite/GUID-D714BF2A-9F4D-4885-8245-F57F3FE121A6.html?cp=5_0_1_3[*1] )