In the first two articles on this topic, I covered how to do a simple signon process and then how to send information...
from your COBOL program to the browser using the write standard output (QtmhWrStout) API. In this article, we'll look at the issue of displaying a list of fields from a System i database file through the browser.
The sample we're going to be working with will display a list of files from a database file on your system that you can create using the DSPOBJD command. In my case, I created the file in my application library using the following CL command:
DSPOBJD OBJ(MYLIB/*ALL) OBJTYPE(*FILE) OUTPUT(*OUTFILE) OUTFILE(MYLIB/FILELIST)
This will create a database file named FILELIST. The file will contain a list of all *FILE objects in the library. If you want a different list of objects, then you can just change the OBJ or OBJTYPE parameter to suit your needs.
In your COBOL program, you need to define the FILELIST file using the file description created by the system. In my case, the following simple SELECT and FD statements is all that's needed:
select file-list assign to database-filelist. . . fd file-list. 01 file-rcd. copy dds-all-formats in mylib-filelist.
In your procedure division, you open this file as input like normal, then you need to start building your Web page data stream to be sent to your browser. This will use the write standard output API as described in my earlier article. For purposes of this example, we will simply perform a routine named "WRITE-OUT" to issue the call to the write API.
The first step is to initiate the HTML stream with something like this:
string HTTP-Header, cr-lf, cr-lf '<HTML>', '<TITLE>Display File FILELIST</TITLE>', cr-lf, '<BODY>', cr-lf, '|' delimited by size into out-data. perform write-out.
Next, you'll need to create a simple page heading. You can make this as elaborate as you want using company logos, graphics or more. In this case, we'll just issue a simple text heading like this:
string '<center>', '<h2>Display File FILELIST', '</h2>', cr-lf, '|' delimited by size into out-data. perform write-out.
For your Web page, it would be nice to have the object information from the FILELIST database appear in columnar format. To do this, you'll need to create an HTML TABLE. To have the column headings at the top of the Web page, I set up the following:
string '<td valign="top" align="right">', cr-lf, '<TABLE border=0>', cr-lf, '<TR>', cr-lf, '<TD><u>Library</u></TD>', '<TD>Object<br><u>Name</u></TD>', '<TD>Object<br><u>Type</u></TD>', '<TD>Object<br><u>Attrib</u></TD>', '<TD><u>Description</u></TD>', '<TD><u>Size</u></TD>', cr-lf, '</TR>', cr-lf, '|' delimited by size into out-data. perform write-out.
Note that the only fields from the FILELIST database that we will be presenting are the library name, object name, object type, description and object size. You can vary this as needed. The DSPOBJD command that creates the file includes a lot of information for you to work with.
The last step in the process is to actually read the database file and insert the database fields into the page. This can be done with a simple read-write loop like the following:
read-files. read file-list next record at end go to end-of-file. process-this-record. move ODOBSZ to dsp-size. string '<TR>', cr-lf '<TD>', ODLBNM, '</TD>', '<TD>', ODOBNM, '</TD>', '<TD>', ODOBTP, '</TD>', '<TD>', ODOBAT, '<TD>', '<TD>', ODOBTX, '</TD>', '<TD align="right">', dsp-size, '</TD>', cr-lf, '</TR>', cr-lf, '|' delimited by size into out-data. perform write-out. go to read-files.
Some things to note here are that the numerical data for the object size is in packed form from the database file. To make it presentable, it is first moved into a character field with a picture definition of all Z's. Also for ease of viewing, this field is displayed within the table with the align setting set to "right".
My sample program simply creates a single page that lists the entire contents of the database. If you create a huge test file, then it will take a while to generate the page and the page itself will be quite large. Obviously, in a production environment, you would need to have a way of limiting the contents of the Web page and provide links for moving around in the database file.
One issue with browser based applications is that each time the browser calls a CGI program, there is no direct continuity in the session with the last operation done by the user, like you would have with a traditional interactive application on the System i. Next time around, I'll describe one way to provide this continuity using a server-side technique. This will avoid dealing with cookies, an alternative way to deal with this issue.
If you have any questions about this topic, you can reach me at firstname.lastname@example.org, I'll give it my best shot. All email messages will be answered.