RE: ILE philosophy

>Is the service program approach really
>the bees knees?

Yes, yes, a thousand times yes!

>What have you done to KISS the maintenance
>of the service programs?

Make several service programs, segregated by function.  Say, higher-math,
string, date/time, sockets and so forth.  Put them all in one binding
directory and let the compiler figure out what service programs it needs.  I
have exactly zero programs that use bind by copy.  Every one of my service
programs uses binder source, with hard-coded signatures.

>Do you have one huge service program, or a bunch of
>smaller ones?  How do you decide which functions belong in
>which service programs?

The major consideration may well be static storage.  When you make a call to
any procedure in a service program, ALL the storage for ALL the procedures
in that SP is initialised.  If you have many simple procedures with little
static storage, then there will probably be an imperceptible hit on
performance.  If you have a procedure that has a large chunk of local
storage, the system will pause to initialise that storage even if you never
call that procedure.

As always, performance questions are best answered by 'it depends.'  Suggest
you try it lumping all modules in a single SP and breaking it up into
several SPs.  Because the source code/modules don't care what SP they get
bound into, you can readily re-bind the program into several small SPs or
one big one rather easily.  There's nothing like modelling the situation on
YOUR machine with YOUR data to answer questions like this.

The ILE Concepts manual has some information on this, as does the Redbook.
  --buck