On 3/12/2014 1:39 PM, Jonathan Wilson wrote:
Hi all, I have been out of touch with the "400" for quite a few years,
so never really got around to learning the new ile specifics.
Hi Jonathan!
I'm not overly pedantic about this, but it will serve you well to search
the internet for IBM i rather than AS/400. Even iSeries as a search
term will get you more current results than '400'. The current
Infocenter is at
http://publib.boulder.ibm.com/eserver/ibmi.html V5R3
is at
http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp
THE introductory reference is the RPG Redbook entitled 'Who Knew You
Could Do That with RPG IV? A Sorcerer's Guide to System Access and More'
http://www.redbooks.ibm.com/abstracts/sg245402.html It's bee around a
while, but given that you're working with V5R3, there's nothing in there
that won't compile.
Scott Klement
http://scottklement.com/ has some interesting RPG examples.
I have managed to get some access to a V5R3 system (I think it is,
pub1.de), and so want to get up to speed as quickly as possible with a
view to getting back into working with the /i.
What I intend to do is take an old "template" combined
workwith/edit,change,view,delete program I created for use in various
sites and update it as far as possible to use as many of the new
features as can be half inched into it. (sql, sub procedures,
getters/setters/free format/encapsulation/etc.)
It sounds as if you have some experience with Java, or at least some
other platforms. Aside from inheritance, most of the procedural
concepts carry over into ILE quite nicely.
procedure sfl1fill
call procedure setllfile
call procedure readfile
call procedure filetosflfields
etc.
Within the "main" portion of the template program
(myworkwithprogram1/2/3/etc.) would be sub procedures (stubs) and these
would be called setllfile/readfile and the programmer would have to edit
which files were accessed/how etc... very much how existing template
programs were done in the past.
It would contain the following..
procedure setllfile
program specific code
procedure readfile
program specific code
procedure filetosflfields
move filefield>s1field
more program specific code
etc.
Now my question is, can a service program/or module or some other type
see (or be made to see) procedures that exist within the code that is
calling the service program that although "defined" in some way, have
wildly varying code within it, such as differing file names, key fields,
etc, but will have a non changing fixed parameter list to the
procedures.
Scott Klement has a useful example of callbacks using procedure pointers
in the FTPAPI open source project. Look up PROCPTR.
I hope this makes sense? I guess in "PC" speak its the equivilent of
"header" files which define the template parameters with the actual
implimentation written in other C files, and a nice be long compile
pulls everything together to a final single program/application.
Well that's something a bit different to what I was describing. In
essence, you mean to have a header that has one PR (prototype) called
say fill_subfile (we can use real names now instead of cryptic
abbreviations!) and at compile time be able to copy in the PI that would
be specific to one and only one of:
Item list
Customer list
Invoice list, etc.
You could do that with conditional compilation (reference /DEFINE and
/IF DEFINED()). I don't think many RPG programmers work that way, for
one reason in particular: If you need to change the
implementation-specific details, you need to find and recompile all the
programs which call it. You won't be able to do that with most cross
reference tools, because EVERY subfile program would simply be making
calls to fill_subfile. From a program logic perspective, NO program
calls the logic that fills an invoice list - only the header (reference
/COPY) for the specific PI (procedure interface / implementation) tells
you.
I can't speak for any RPG programmer except myself. I do these things
with a service program. That way, when the implementing logic changes,
I don't need to hunt down all the callers and recompile them. One
compilation, one update of the service program and all the callers get
the new logic. For me, an added benefit of the service program approach
is testing. I test the subprocedures in the service program with RPGUnit.
You can still implement table-specific code in the service program, only
instead of conditional compilation, use a wrapper function. So your
fill_subfile() might take an additional parameter which would look
something like this:
callp fill_subfile(CUSTOMERS: custID: page_size);
d fill_subfile PI
d table_id like(table_id_template) value
d table_pri_key like(primary_key_template) value
d subfile_page_size like(subfile_size_template) value
c/free
select;
when table_id = CUSTOMERS;
callp fill_customer_subfile(table_pri_key: subfile_page_size);
when table_id = PRODUCTS;
callp fill_product_subfile(table_pri_key: subfile_page_size);
...
endsl;
CUSTOMERS and all the _template fields would be defined in the same
/COPY member (I put mine in QPROTOSRC) that defines the prototypes for
fill_subfile, fill_customer_subfile, fill_product_subfile, etc. So all
the pieces to compile this are in one place.
This is probably information overload; I'm sorry. Repetition will bring
better understanding. For now, create a simple service program that
does the simplest thing. In my day, it was the 80-80 list, today, it's
Hello, World. Have your Hello, World subprocedure take your name as an
input parameter, and do something like DSPLY to put the Hello, Jonathan!
on the screen.
I love ILE and service programs, but even if you choose to avoid them in
favour of procedures 'completed' at compile time, the power of
sub=procedures can't be underestimated. Local variables alone will make
your RPG much more robust than the monoliths of yore.
Welcome to modern RPG!
--buck
midrange.com
