ILE philosophy

[Rich Duzenbury <rduz@xxxxxxxxxxxxxxxxxxx>]

I am at the ILE crossroads today.  I understand OPM RPG well.  I understand
basic RPG IV (That is, a self contained ILE program) programming well.  I
can create a module and make it work with my main program, no problem.

I'm not sure how to manage all my modules yet.  I think I have to select
the high road or low road now.

Currently, I'm looking at the low road:  Add each module to a binding
directory.  Upon changing a module, recompile every program that uses that
module.  Not too difficult, and something I'm used to in the event of, say,
a database change.  Positives: Simple.  Bind by copy is fast at
runtime.  Negatives: have to recompile, perhaps the world, for some changes.

Now the high road: Add each module to a service program.  Add service
program to binding directory.  Upon changing a module, recompile service
program.  Muddle around with binder language source and signatures
(?).  Hope that everything stays up-to-date and
working.  Positives:  Changes can be made without having to recompile tons
of code.  Negatives: Bind by reference is slower at runtime.  Seemingly
much more maintenance hassle to deal with the signatures and binder
language source.

Perhaps I'm wrong here because I haven't used service programs.  Is the
service program approach really the bees knees?  What have you done to KISS
the maintenance of the service programs?  Finally, how do you manage your
service programs.  Do you have one huge service program, or a bunch of
smaller ones?  How do you decide which functions belong in which service
programs?

And a last aside:  I took a look at binding directory QC2LE for hints.  It
is made up of service programs that are made up of other service programs,
and sometimes modules.  Is it normal (even desirable) to build a heirarchy
of service programs?

Thanks in advance for your thoughts.


Regards,
Rich