Workstation Interface

If you're interested in deploying an HTML interface from legacy RPG
applications, you might want to consider this.

Most RPG programmers are familiar with the OS/400 workstation interface.
The idea is to use traditional WRITE and READ opcodes in conjunction with an
externally described display file to interface with 5250 clients.

What about borrowing from that idea to interface with browsers, instead?
Rather than having the I/O opcodes transfer control to an OS/400 routine,
have them transfer control to your own procedures that generate an HTML
formatted stream, and forward the result to the HTTP Server, which sends the
result to the browser.

This has been the subject of an R&D effort I've been working on.  Following
are a set of screen shots, which depict some results.  The Client Access
version of a screen is followed by an HTML version (which is depicted in 3
different style sheet themes):

http://www.relational-data.com/rdweb/rd1200s/green.html

The idea is to convert the display file DDS to an HTML template.  For
example, here's a fragment of the HTML template that defines the subfile
record depicted in the screen shots.

<!RECORD:SFLREC>
<tr>
<td nowrap align="center" class="sflrow">
<INPUT CLASS="WHTHI" NAME="{{{SFOPT}}}"
VALUE="{{SFOPT}}" SIZE=1 MAXLENGTH=1>   </td>
<td nowrap align="left" class="sflrow">{{WAID}}</td>
<td nowrap align="left" class="sflrow">{{WAPGNM}}</td>
<td nowrap align="left" class="sflrow">{{WAPGLB}}</td>
<td nowrap align="left" class="sflrow">{{WAJBNM}}</td>
<td nowrap align="left" class="sflrow">{{WAJBLB}}</td>
<td nowrap align="center" class="sflrow">{{WALGRQ}}</td>
<td nowrap align="center" class="sflrow">{{WALGRP}}</td>
</tr>

Nothing fancy in the HTML template.  Just a row in an HTML table, plus
record and field markers.  It's easily modified by any WYSIWYG HTML editor.
Field names are delimited by curly braces.

The generated HTML stream (that is eventually returned to the browser),  is
controlled first by the Write statement in the legacy program, as follows:


C                   Write     sflrec


But in this case, the Write opcode transfers control to an RPG procedure
that is named after the opcode (Write) and the record format (sflrec), as
follows:


P WR_SFLREC       B                   EXPORT

C                   CallP     wwkRecSet('SFLREC')

C                   CallP     wwkFldSet('SFOPT':SFOPT)
C                   CallP     wwkFldSet('WAID':WAID)
C                   CallP     wwkFldSet('WAPGNM':WAPGNM)
C                   CallP     wwkFldSet('WAPGLB':WAPGLB)
C                   CallP     wwkFldSet('WAJBNM':WAJBNM)
C                   CallP     wwkFldSet('WAJBLB':WAJBLB)
C                   CallP     wwkFldSet('WALGRQ':WALGRQ)
C                   CallP     wwkFldSet('WALGRP':WALGRP)

C                   CallP     wwkSflWrt('SFLREC')

P WR_SFLREC       E

Although located in a separate module, this procedure has access to the
record buffers defined in the legacy program, along with access to the HTML
template.  The generation of the HTML stream becomes a matter of setting the
field values, and storing the result in a buffer which is returned to the
HTTP Server.

Likewise, to process any changes to the subfile record, the legacy program
uses a Read opcode, as follows:

C                   Read      sflrec

The Read opcode transfers control to the following procedure:

P RD_SFLREC       B                   EXPORT

C                   Eval      WT_EOF = wwkSflRdc('SFLREC')

C                   If        Not WT_EOF
C                   Eval      sfopt = wwkSflFldGet('SFOPT')
C                   Eval      waid = wwkSflFldGet('B_WAID')
C                   EndIf

P RD_SFLREC       E

The wwkSflRdc procedure reads the next changed subfile record.  If a changed
record exists, then applicable field values are retrieved and returned to
the legacy program.

One advantage of this streamlined interface is performance.  The HTML
screens depicted in the screen shots are returned in about 200 milliseconds
from my model 170-2290.  That's perhaps at least 100 TIMES more efficient
than Webfacing, based on some reports.  And requires ZERO interactive CPW.

This new interface requires one new HTML file and one additional ILE module
per display file.  The ILE module is pretty simple, though.  I'm still
working on some of the plumbing for this interface, but thought that a
preliminary progress report might be of interest to some of you.

Nathan M. Andelin
www.relational-data.com

Copyright (c) 2002 Nathan M. Andelin, all rights reserved.