RE: ILE philosophy -- RPG400-L

At 09:37 AM 9/20/02, you wrote:

I've always followed the standard of putting similar procedures in one
service program, like all message-handling procs, or all string-handling
procs, and that seems to work very well.  In that scenario, I've never found
the need for more than one module per service program.

I had not thought of this approach.  In my mind, my plan would be to have
lots and lots of modules. For example, one module with date procedures, one
with string procedures, and so forth and then group them together into a
much smaller number of service programs.  This is ingrained thinking from
the bad old days of C programming.  Lots and lots of .c program files make
lots and lots of .obj files that get combined into just a few .lib files.

The system I'm used to working on has, just in one little application
corner, about 400,000 lines of OPM RPG code.  I can see at least extracting
all of the utility functions that are copied from program to program and
sharing them through a binding directory.  For purposes of discussion,
perhaps there are five hundred unique utility subroutines scattered about
this application, and that we wind up grouping ten of them into each
service program.

Should I be concerned that my application program may need to open up to
fifty service programs?

It seems a bit excessive....

If you have more
than one, that may be an indication that you need to break down the service
program to more discrete sets of procedures.  Your best and most useful
service program procedures will be those that only do one small function. If
they are built that way, it should be easy to group them into task-related
service programs.  If your procedures perform more than one function, they
probably need to be broken down further.

Yes, where you say 'service program', I'm thinking module, but I do believe
that grouping like functions together as as some kind of unit will be much
better on many fronts.  For example, a developer should be able to
concentrate on a very small chunk of an very large application, and keep it
all in his head.  It should be fairly easy to devise a test program that
exercises each function and reports whether or not it worked.  Of course,
in the OPM world we call these sub-programs, and we've been doing that for
decades.