This month, we want to introduce you to another simple RPG Open Access (OA) handler—this one provides the capability to convert a printer file report program to output on the Web. In previous articles and blogs related to OA, we noted that writing a handler to convert 5250 applications to the Web was probably not something you would want to do in-house. Better to purchase one from an experienced vendor and take advantage of their experience. However, converting a printer file to output to a browser is a somewhat simpler task—although not without its challenges.
We first approached the topic of “webulating” report programs in 2001 in a three-part series that started with “RPG for the Web.” In the third part, we introduced the notion of simplifying the Web-programming process by using the CGIDEV2 toolkit, a topic we’ve revisited for many reasons over the years. CGIDEV2 has a major advantage by using a templating system that lets the HTML be separated from the program logic in much the same way as DDS-defined printer files let us separate the layout of a report. This way the layout of the report can be changed without impacting the logic of the program—unless of course you’re adding new record formats and/or fields. Since CGIDEV2 is a free download, we decided to once again use that as our foundation.
That original approach utilized an RPG SPECIAL file, which we’ve noted has several limitations—the major one being that to have a generic “file,” you must sacrifice formatting options. Alternatively, you can write a custom “file” for each report, or write a very sophisticated “file” that uses APIs to interrogate the printer file to determine the buffer layout. Even then, you may still have problems working out which record format is which. Neither of these options is desirable if what you’re trying to achieve is the fast and simple webulation of a print program.
Open Access to the Rescue!
When we first heard about OA, one of the first things we thought about was revisiting the whole printer webulation idea—but it seemed a little complex for our initial experiments. Turns out we were wrong—it’s actually very simple as you’ll see. The real difficulty was in determining the architectural details. Once we had figured those out, the rest was easy.
So how could we make the process generic? First of all, we require a separate template for each printer file. We decided that if we always used the same location in the IFS to store those templates, and always used a common suffix for the file names, then we could use the file name supplied to the handler by OA to form the name of the template. Similarly, we decided if we used the names of the record formats and fields from the printer file as the section and substitution variable names, we could easily populate the values and determine what sections to output from the data supplied in the main OA structure and Name/Value information that’s passed on each request.
Here, you can see an extract from the original printer file DDS and the corresponding HTML skeleton. Notice the correlation of the names used.
Extract of Printer file DDS
A R DETAIL SPACEA(1)
A CATCODE R 3
A PRODCODE R 10
A DESCR 30 21
A SELLPRICE R 57EDTCDE(K)
A DISCPRICE R 72EDTCDE(K)
A QTYONHAND R 86EDTCDE(K)
A R CATTOTALS SPACEB(1)
A 1'Values for category: '
A XCCATNAME 30A 22
Extract of corresponding portion of HTML template
<!-- Detail -->
<td width=75 height=39 align="center">/%CatCode%/</td>
<td width=75 align="center">/%ProdCode%/</td>
<td width=300 align="left">/%Descr%/</td>
<td width=100 align="right">/%SellPrice%/</td>
<td width=100 align="right">/%DiscPrice%/</td>
<td width=100 align="right">/%QtyOnHand%/</td>
<!-- CatTotals -->
<td colspan=2 height=39>Values for category:</td>
<td width=300 align="left">/%XCCatName%/</td>
Additionally, we decided we’d use a standardized name (Footer) for a final HTML section that would be used to wrap up the HTML.