RE: ILE philosophy

Again strictly my opinion and may not be the best practise, but I think of
*SRVPGM as *LIB.  Yes, an OS/400 library object.  I put all my payroll
specific procedures in one service program.  I put all my utility procedures
(like number to words, centre text, trig functions) in utility service
programs.  I segregate them according to function.  I am highly likely to
need date handling and text manipulation in the same mainline, so all those
functions are in a single SP.  I only rarely need sockets functions, so they
live in their own SP.  It's a convenience thing more than anything else.

This all matches OPM behaviour pretty closely.  Separate library for each
application and a single library (or small number of them) for cross
application needs.  No scheme will be perfect.  Sometimes a P/R procedure is
just the thing for some G/L program.  Since I have but one single binding
directory that holds all service programs, the compiler goes out and binds
the right service program for me.  I see less maintenance rather than more.

As for 'one module, one service program,' I say that it depends entirely on
the application.  Often, it makes sense to have global status variables,
buffers and so on.  If I put all my procedures in a single module, then all
have access to those variables.  But sometimes I need more localised
'global' storage, and then I put those procedures in their own module.  But
more often than not, one module per service program works just fine.
  --buck