Here's my $.02 of assistance. There are a number of ways to get data from
RPG programs to populate a GUI, whether it be in a web browser or a rich
client/fat-client application. Here is an example of an OO approach for
the .NET platform ("N-layer design"):
http://imar.spaanjaars.com/476/n-layered-web-applications-with-aspnet-35-part-1-general-introduction
The example is for C# and VB.NET in ASP.NET, but the principles could be
applied in Java, PHP, etc. You could write reusable object wrappers in a
data access layer, which map to files (tables) in DB2. Typically, these
use something like a ADO.NET, JDBC, ODBC, etc. connection to retrieve data
from DB2 using SQL. (There are also various ORM (object-relational
mapping) frameworks available for doing this in various languages, but I
do not have enough experience with them to know the trade-offs between
functionality provided and granularity and integration with DB2.) As an
alternative to heavy use of SQL, however, you can re-use RPG programming
for data retrieval by creating UDFs (user defined functions) from RPG
sub-procedures in a service program. You would still have to use one of
the connection technologies and SQL, but could still re-use your RPG code.
Your RPG data access and business rules need to be modularized first into
sub-procedures residing in service programs. Many writers like Scott
Klement have written articles on this (thanks, Scott!). For example:
http://systeminetwork.com/article/udtfs-and-subfiles-make-great-pair
Another approach as advocated by Aaron, Henrik, et. al. is to use
Javascript in a browser front-end to talk with RPG CGI programs and DB2 on
the back-end. CNX provides some useful training videos for their Valence
software, which can help for understanding this model (
http://www.cnxcorp.com/valence/training/).These programs send JSON-encoded
data to your Javascript front-end for presentation in the browser. As a
previous poster mentioned, another (less-conventional) approach for
in-house apps. would be to write an RPG program which routes data via
sockets connections to fat or rich-client apps. that could then be parsed
and used to populate drop-downs, grids, etc. Scott Klement has again
provided a lot of examples and information regarding writing sockets
applications in RPG (
http://www.scottklement.com/rpg/socktut/index.html).
The most important thing is to write modular code as is stressed over and
over again by people on this list. Separate concerns by breaking your data
access logic and business rules into RPG service programs or what have
you. If architected properly, you can then re-use that logic any number of
ways, whether it be for a 5250, browser or fat-client application. I'm not
saying anything a lot of people on this list don't already know (and
better than myself), but maybe it will provide a starting point.
Blake
From:
rpg400-l-request@xxxxxxxxxxxx
To:
rpg400-l@xxxxxxxxxxxx
Date:
07/29/2010 10:55 AM
Subject:
RPG400-L Digest, Vol 9, Issue 580
Sent by:
rpg400-l-bounces@xxxxxxxxxxxx
------------------------------
message: 2
date: Thu, 29 Jul 2010 11:43:01 -0400
from: "Mark Murphy/STAR BASE Consulting Inc."
<mmurphy@xxxxxxxxxxxxxxx>
subject: Re: Future of RPG
Granted there is a lot to learn, but happy users don't generate as many
service calls.
One thing that can help is to pick a framework. You mentioned PHP. Try
Zend Framework or Symfony. Zend Framework can connect directly to DB2 on
the i. For Symfony you will need to use MySQL with the DB2 storage
engine. Zend Framework is far more complex, and far more flexible.
Symfony will have a shorter learning curve.
Pick an IDE. RDp provides for RPG development, and since it is built on
eclipse, you should be able to add the PDT plug-ins for PHP development.
SEU is really insufficient, and as I found, once I got used to using
WDSCi, I couldn't go back to SEU.
All of this will take some time to learn, but once you do you will be more
productive for it.
Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx
-----rpg400-l-bounces@xxxxxxxxxxxx wrote: -----
To: RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>
From: THarteau@xxxxxxxxxxxxxxxxxx
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
Date: 07/28/2010 02:31PM
Subject: Future of RPG
Hi,
I would love to learn and do new things! We have an ERP package
that is written in RPG400, some old home grown programs in RPG III and
anything new is in RPG 4 with a little bit of ILE. New requests are
wanted tomorrow and maintenance to existing programs need to be fixed
yesterday. We have 2 programmers, counting myself. Not a lot of time for
figuring out new stuff when the old stuff is faster.
Take this as an example, we just finished a maintenance program
using green screen. The user really wanted a PC like screen with drop
down boxes and radio buttons. Almost every entered field was validated
against a DB2 file before updating several different master files.
It was done in green screen because we are missing the information
on how to make a GUI front end work with RPG. How can you do this
efficiently with RPG doing most of the work? I have taken a couple of
hour long sessions on PHP & EGL, but how does the data go between the
screen & the program? I understand the syntax, but the implementation is
what I have a problem with, and don't have the time to figure out. How
can passing all the fields (20+) through the IFS or something else be as
fast as a green screen with subfiles? I haven't looked extensively, but I
have not seen step by step instructions on how to make a GUI screen work
with RPG. I have seen how to write the screen, how to write the program,
but how is the information passed back and forth? This may not make a lot
of sense, but this would have been a perfect project to use new
techniques, but I did not see a fast way to get it up and running.
<===================================================>
Terri Harteau
Felker Brothers Corporation
****************
"Do not follow where the path may lead. Go instead where there is no path
and leave a trail."
Ralph Waldo Emerson
****************
midrange.com
