What's keeping you from doing Web-based development? Are you considering it? When I go to a client to train their staff, I'm training them on intermediate to advanced RPG IV. I teach this over a two-day period followed by a third day of hands-on lab. Lately, however, on the last day, I'm being asked to "do a little on Web development with CGI and RPG IV."
I love writing CGI RPG IV. In fact, lately, it is the only RPG IV programming I do. But what is CGI RPG IV? For that matter, what is CGI?
Overview of CGI
Nearly every Web server includes support for the Common Gateway Interface (CGI). The only exception is Apple Computer's Macintosh Web server, but it supports a technology that is somewhat similar to CGI.
In the world of movie-making, CGI stands for Computer Generated Images. But to the World Wide Web, CGI is the interface that provides a Web server with the ability to facilitate program call requests. In other words, it is the interface that allows RPG IV programs to be called as a result of pressing the Submit button on an HTML page. CGI programs can generate dynamic HTML, update databases, and do just about anything a normal program might do.
The best thing about CGI is that it is language-neutral. That is, if you only know one programming language, the odds are pretty good that it can be used for CGI programming. On AS/400 and iSeries systems, any ILE-targeted language can be used as a CGI language. This includes RPG IV, C, C++, COBOL, and even the ILE version of CL. RPG III can be used as a CGI program, but it cannot easily interface with the OS/400 CGI APIs. It is also possible, obviously, to call RPG III programs from CGI programs written in other programming languages.
What Is a CGI Program?
Filling in an HTML form with your name and address and other information seems to be an ongoing theme on most Web sites today. After the data has been typed into the form, the end user typically presses a button marked Submit. The data is sent to the Web server, and your information is forever in someone's data warehouse. But what really happens when the Submit button is pressed?
Pressing the Submit button on an HTML Web page usually causes a program on a server to be called. The Web server itself actually calls the CGI program in response to a request made by a Web browser. The Web browser gathers up the data from the HTML form and makes it available to the called program. The called program retrieves the data entered on the HTML form, processes it, and usually sends the Web server a reply. The program being called on the server is known as a CGI program.
Calling CGI Programs
CGI programs are called by the Web server, but they are requested by the Web browser. Effectively, the Web browser sends the name of the program to be called to the Web server. The Web server then calls the CGI program.
The syntax for calling a CGI program is nearly the same as typing a Web address into a Web browser. This syntax, known as URL encoding, can be either typed in by the end user to evoke a program (rarely) or embedded in an HTML page and called up by some other mechanism. The syntax to call a CGI program is as follows:
This URL-encoded string breaks down as follows:
URL Encoded String Component
The URL of the server
The virtual path on the server where the file or CGI program is located. This may or may not be a real path on the server. The HTTP configuration file (on the server) can map this virtual path into whatever real path the application requires.
The CGI Program name to be called
The data passed to the program. The question mark identifies the start of the parameter list. The USRPRF keyword identifies the name of the first parameter, and COZZI is the value assigned to that parameter. The ampersand (&) between the first parameter's value COZZI and the PWD keyword is a parameter separator. It identifies the start of the next parameter. In this case, the second parameter name is PWD (password), and it is assigned the value STARFISH.
A CGI program can be called by using any of the following methods. Each method uses the same URL-encoded string syntax.
- In response to the SUBMIT button on an HTML form
- In response to an end user clicking on a hyperlink
- As a URL address entered directly by an end user
- As a server-side include
When a CGI program is called in response to a Submit button request, the compete URL-encoded string is generated by the Web browser. The other methods require the programmer to build the URL-encoded string correctly.
CGI Application Programming Interfaces (APIs)
IBM OS/400 includes a set of APIs that enables RPG IV to function as a CGI programming language. Since CGI programming is based on the UNIX operating system's I/O processing, most programming languages not originating on the IBM midrange product line have CGI functionality built in. These other languages--including C, Java, and C++--can avoid utilizing many of the APIs featured in this section.
The CGI APIs provide a method of communication between a Web browser and programs, through the Web server. In addition, a few utility APIs provide additional functionality directly related to CGI programming issues. The available APIs for CGI programming include the following.
Get a value from the CGI environment
Change a value in the CGI environment
Read a string from the standard-input device (i.e., read data sent to a CGI program from an HTML form)
Write a string to the standard-output device (i.e., write to the Web browser)
Convert URL-encoded string to an externally described data structure
Parse the data from an HTML form
"Utilities" to create a full HTTP response
These APIs are referred to as bindable APIs. That is, they are procedure calls, not program calls. Consequently, in RPG IV, the CALLB or CALLP operation codes must be used to call these APIs. In addition, the API names are case-sensitive.
These APIs exist in a service program (*SRVPGM) object in OS/400. The service program name is QZHBCGI and is located in the QHTTPSVR library.
To avoid incorrectly specifying the names of the bindable APIs, named constants are often created and referenced instead of the API names themselves. This allows case-insensitive names to be specified in Factor 2 of the CALLB operation code and the EXTPROC keyword. The example that follows illustrates a set of name constants that can be used in place of the API names.
D cgiGetEnv C Const('QtmhGetEnv')
D cgiPutEnv C Const('QtmhPutEnv')
D cgiRdStin C Const('QtmhRdStin')
D cgiWrStout C Const('QtmhWrStout')
D cgiCvtDB C Const('QtmhCvtDB')
D cgiParse C Const('QzhbCgiParse')
D cgiUtils C Const('QzhbCgiUtils')
One of the most frequently used interfaces is the QtmhWrStout API. This API allows you to send HTML or other source to the Web browser. Many of the things you need to send to the Web browser require a line-feed character. For example, the heading for your HTML text usually includes one of the various CGI Headers, such as Content-Type, Status, or Location. Each of these requires a line-feed character to follow them.
Unfortunately, the compiler writers didn't include any native support for CGI programming RPG IV. So even something as simple as a line-feed character needs to be embellished in RPG IV. The line-feed character translates to X'15' in RPG IV, which means concatenation is required. For example, to create "Content-type: text/html" followed by two-line feed characters, the following RPG IV statement can be used:
In all other CGI languages, the line-feed character is represented by a symbolic "escape" character. That is, if you embed a backslash followed by a lower case n, the symbol is converted into a line-feed character. If this support were provided in RPG IV, the following would be allowed:
By supporting this symbolic line feed, numerous concatenations can be avoided. Fortunately, I got fed up with constantly doing concatenations and wrote a wrapper API around QtmhWrStout. I call this wrapper STDOUT (Write to Standard Output).
The STDOUT procedure wraps the CGI QtmhWrStout API by allowing the caller to simply specify the HTML text to be sent to the browser without concern for embedding X'15'. It does this by scanning the input text for embedded symbols and translates them into X'15' before sending the HTML text to the QtmhWrStout API.
Syntax and Parameters
The first parameter is the HTML text to be sent to the browser. Any valid HTML may be specified. In addition, embedded symbols are automatically translated to X'15' for use by the QtmhWrStout API. The parameter is a VARYING length field, which is used to determine the true length of the data being sent to the browser. This avoids requiring the length to be specified on the STDOUT API itself.
The return value is the length of the text that was sent to the browser.
Rather than post the entire STDOUT procedure's source in this issue, I've made it available for free download as a source member (ASCII text file). To download the source code for the STDOUT procedure, follow this link.