Re: Who's doing Web work on iSeries? (was: ASP on AS/400Apache)

Joel, actually it's not 1 screen = 1 program...at least not for my shop.  In
my shop we were looking for a way to move our green screen apps to a GUI and
do it fast.  We started with Net.Data but quickly discovered we needed more
than just query and SQL style applications.  We then too a look at Brad
Stone's book eRPG which turned us on to CGI.  Then after some additional
research, we discovered CGIDEV2 which took much of the manual work out of
programming CGI applications.

Now just 6 months later we have a menu processor, and 10 RPG CGI apps all
running with incredible performance and functionality.  We plan on moving to
the Servlet model as Joe Pluta's book suggests but for the short term CGI is
the answer for us.

One of our goals was to be able to build robust apps that could re-use
functionality.  We wanted to build for example an employee search CGI
program then use it in our other CGI apps.  We also didn't want to have as
you stated 1 screen = 1 program so we devised a way to write 1 program and
have it do many functions.

So for the first objective we made a common data structure (we call it the
CGICDS) with all peritinent fields then passed it as a variable from one
program to the next.  By using this approach, we also met our second
objective.

Here's an example:  We wrote an application to display an employee's photo
and some other information.  We wrote 2 programs, the employee search and
the employee viewer.  The user starts by launching our 'Web Menu'.  The web
menu first gives them a login screen.  The login button is actually tied to
a function which sets a hidden variable on the form to "Login".  When they
press the 'login' button, the menu is launched (called) again but this time
since it sees the function is "Login" it executes a subroutine to perform a
user validation.  If they pass, it reads a database file and builds a screen
of icons and hyperlinks.  Here's the secret....each hyperlink is tied to a
function which sets some variables on a hidden form then does a 'submit'.

OK so assuming the user was validated, they are now looking at some icons,
on of which is the 'Employee Viewer'.  If they click the employee viewer
icon or hyperlink, the function linked to the icon and hyperlink is run
which is dynamically set to submit the 'employee viewer' program.  The
employee viewer RPG CGI program starts running and reads in the CGICDS.

First thing is does is check for a user.  If there is no user, it presents
it's own login screen (this is in case users bookmark web applications
directly instead of launching from the menu).  If the user is present it
checks for the requested employee.  Since this is the first time, the
'selected employee' is blank so we 'write' a CGI section that immediately
submits a form to the employee search program.  Included on that submit is
of course the CGICDS which includes a field for 'target' program.  So the
employee search program 'loads' displaying a simple "search data" entry box.
When they enter a name and press search, we remain in the search program but
this time return a list of employees.  Each employee is a hyperlink and it's
target is a function which submits the 'target' program passed to it when it
was initially called.

So finally when an employee is clicked, the original program is called once
again but this time since it has the selected employee, it returns a web
page with the employee photo and other data.

Now, one last note, we use the POST method for all this work.  By using this
the user does not see this data in the URL.  True they can see it in the
source but the typical user won't view the source and even if they did they
would not be able to recraft a submit and POST the data without some
sophistication.  Shortly we'll be encrypting the CGICDS anyway and only the
RPG programs will know how to encrpyt/decrypt the data and the key will
change daily so we think it'll be pretty secure.

I hope I didn't confuse everyone.  Unfortunately I cannot demonstrate this
live because these applications are running on a production system.  But I
can say that we've exploited CGI RPG programming on our iSeries.  End users
have no idea they are looking at an iSeries app.  It looks and feels like a
regular web application.  The web menu and CGICDS method enables us to use a
modular approach for specific functions then call them as we need them.  We
write one program per application which may consist of many HTML screens.
By using the CGICDS, we pass a function code that tells the program which
function we want.

Here's another brief example without all the detail to cement what I am
saying about using 1 program for multiple HTML pages.  We have a Humam
Resources app that displays an HTML page that presents what looks like tabs.
There's a tab for Demographics, Pay History, Benefits, Position, etc).  Each
tab (which is really just a colored HTML table cell) is linked to an
individual JavaScript function which sets the requested function then
submits the same program.  The program is called, reads in the CGICDS, sees
the function, then runs the requested subroutine which rebuilds the tabs
plus writes out the selected tab page.

Again, I can't stress enough how powerful RPG CGI programming can be.  In
this day where many perceive RPG and the AS/400 (iSeries) as dead or dying,
if enough people showed just what could be done using this technique, the
AS/400 and it's proven business applications may just get a new lease on
life.



----- Original Message -----
From: "Joel R. Cochran" <jrc@masi-brac.com>
To: <web400@midrange.com>
Sent: Thursday, December 20, 2001 7:01 PM
Subject: RE: [WEB400] Who's doing Web work on iSeries? (was: ASP on
AS/400Apache)


>
> >> The formula in HTML with CGI is 1 screen = 1 program.  At first
> >> this sounds
> >> horrible, but you realize immediately you are not limited to
> >> 24x80 anymore!
> >> You can scroll, have popups, open seperate windows, and all kinds
> >> of stuff.
> >