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.