That's absolutely doable. I wrote a similar routine for processing XML
files. All the "complicated" XML code is in a service program. When the
calling program utilizes a procedure in the service program, it passes
procedure pointers that the service program uses to return to the
calling program to perform file-specific processing.
Trevor Briggs
Analyst/Programmer
Lincare, Inc.
(727) 431-1246
TBriggs2@xxxxxxxxxxx
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Wilson Jonathan
Sent: Wednesday, March 12, 2014 1:39 PM
To: RPG programming on the IBM i (AS/400 and iSeries)
Subject: Subprocedures..
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.
As this is my first post to this group I hope this email suits all the
requirements.
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.)
With this end I have a question about using/creating sub procedures (I
think they are called) and as to how I can define them, use them, and
"hide" an implementation of the basic working structure of the program
and just expose the bits needed to make a unique program, if such a
thing is possible.
A simplistic example of part of the program would be a slf "work with"
view... the logic original subroutines were along the lines of...
*enter
exsr sfl1fill
exsr setllfile
begsr setllfile
setll namedfile
< return
exsr readfile
begsr readfile
readf namedfile
< return
etc...
Now it seems to me that sfl1fill could all be "hidden" in a service
program (workwithlogic) that purely maintains the program flow logic and
as such would be written once and re-used in a multitude of programs.
It would contain the following...
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.
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.
If so, is there any simple examples, or pointers to manuals/red books
that show this kind of thing.
Thanks in advance, Jon.
midrange.com
