COBOL CGI Interface

Perhaps you want customers or users to run your applications by clicking a link on your Web site, but you don't want to require anything special of the user's machine (for instance, the presence of any ACUCOBOL-GT runtime, be it a standard, thin client, or Web runtime). In this case, you can create a new interface to your application using a markup language such as HTML, WML, or XML. With a Web interface, your application can be interpreted directly by the user's HTTP browser or mobile device, and the processing logic can remain in COBOL on the Web server.

In this scenario, you create your Web interface using one of many popular authoring tools. Then you write a CGI program that can read CGI variables submitted by the client to the server. This program can launch your COBOL application or it can be a COBOL program itself. You can write it using ACUCOBOL-GT or any other language you choose. If you write the program in ACUCOBOL-GT, you do not have to UNSTRING the CGI variables in the program, because ACUCOBOL-GT takes care of this for you through special "IS EXTERNAL-FORM" syntax.

By default, your CGI program reads and writes HTML content for use in standard HTTP browsers and mobile devices. But using configuration variables, you can associate your program with the MIME content type for WML so that data can be displayed on WML-based devices as well.

Once you build a Web front end and write a CGI program, your customers or users can then visit your Web site and gain instant access to your COBOL application running on the server.

Note that CGI programs are inherently stateless–that is, they do not store information about previous browser actions. If you require a persistent connection to the browser, you can achieve this by adding pointers and cookies to your CGI program, or you may choose a different method.

This option runs on any platform where ACUCOBOL-GT runs, but it also requires the most coding. You can employ the CGI method wherever a user interface via DISPLAY/ACCEPT statements is not used. This includes batch processes, processes that use socket routines to communicate with an external UI, BEA® Tuxedo® processes, and processes launched via AcuConnect in distributed processing mode, to name a few.