RE: Subproc vs Module (WAS: Re: Service Programs VS normal Programs)

Lets say the most technically correct phrase is 'EXPORTED PROCEDURE'.
My first use of ILE and Service Programs was CL, were there is a 1:1
relationship of module to procedure, so I still think of them that way.
A sub-procedure is not automatically EXPORTED, so we can't refer to them
as a sub-procedure either.  (A square is also a rectangle, but a
rectangle is not necessarily a square - Besides, SUB-PROCEDURE is a very
RPG-centric name for a language independent concept.)  

At first I was confused by your statement 'if I don't want someone using
my subprocs, I make it a module', then I realized you meant end-users at
a customer site, not other programmers in your own shop.

Why does everyone seem to fight the signatures on service programs?
They are there to make sure the objects match and do not cause
unexpected results.  With care, old programs can still use updated
service programs.  (Keep the order of the procedures the same, adding
new procedures to the end of the list and use BINDER language to define
a *PRV signature.)  Unless you have customers replacing your service
programs and/or their procedures, how can signatures and parm lists be
out of your control?
 
------------------------------

date: Thu, 26 Aug 2004 14:17:00 -0500
from: "Brad Stone" <brad@xxxxxxxxxxxx>
subject: Re: Service Programs VS normal Programs

Chris,  I think you mean "subprocedure" where you say "module".

As for my rule of them when to use which, if I don't want someone using
my subprocs, I make it a module.  

If I want to make sure there are no worries between subprocs and
programs communicating (when this is out of my
control) (sigs, parms, etc), I use modules.

Most other times, I use service programs.

- Some lines deleted -