Here is an excellent redbook that some of the best minds in RPG wrote for just those purposes:
http://www.redbooks.ibm.com/abstracts/sg245402.html
Alan Cassidy
Senior Developer
Hospital Physician Partners
954-693-0000 ext. 3433 - Direct phone
786-380-9236 - Mobile phone
acassidy@xxxxxxxxxxxxxx
www.hppartners.com
-----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.
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.
--------------------------------------------------------------------------------
Confidentiality Notice: This email may contain confidential information or information covered under the Privacy Act, 5 USC 552(a), and/or the Health Insurance Portability and Accountability Act (PL 104-191) and its various implementing regulations and must be protected in accordance with those provisions. It contains information that is legally privileged, confidential or otherwise protected from use or disclosure. This e-mail message, including any attachments, is for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. You, the recipient, are obligated to maintain it in a safe, secure and confidential manner. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Thank you.
--------------------------------------------------------------------------------
midrange.com
