How CGI Works

The flow of typical CGI implementation is as follows:

1. From a client machine–which could be anything from a Web browser to a mobile phone–a form or query is sent to the Web server. The user might launch a request by pressing a button or clicking a link.
2. The Web server forwards the request to the CGI program, in this case, written in ACUCOBOL-GT. This program ACCEPTs the CGI data sent by the client into an external form which you define in working storage.
3. The request is either processed by the CGI program itself, or passed to another ACUCOBOL-GT program for execution.
4. The CGI program uses the DISPLAY verb to merge processing results with an HTML, XML, or WML template, and sends the result to the Web server in the standard output stream. The ACUCOBOL-GT runtime creates and outputs the appropriate content response headers automatically.
5. The Web server sends the content response header followed by the appropriate content message to the user's machine or mobile device where it is displayed.

Note that this diagram shows the CGI program and ACUCOBOL-GT application as separate components. In many instances, you may choose to add CGI functions directly to your COBOL application, making them one in the same thing.

In addition, any and all connectivity options available to extend customers can be applied in the third step if desired. For instance, the CGI program can CALL a remote program using the AcuConnect® application server for connectivity. Likewise, the CGI program or CALLed program can access any file system or database that we support to perform a lookup. If the file system resides on another machine, the program can use the AcuServer® remote file server to achieve access. If a relational database access is desired, the Acu4GL® interface or AcuSQL® precompiler can be used to translate the request into SQL.

The CGI method is best suited for programs that do not use a user interface (UI) based on COBOL DISPLAY/ACCEPT statements–for instance, programs with a Web interface, batch processes, processes that use socket routines to communicate with an external UI, component adapter technology processes, and BEA Tuxedo processes.