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.

Examples:
Most of the time when programming for a shop, I use service
programs (proprietary software).   This makes updating the
function of the subprocs much easier.  Distributing a new
service program instead of a load of programs bound by
copy.

For most of the software I offer at www.bvstools.com, I use
modules and bind by copy.  Not for speed, but becuase my
modules contain subprocs that I don't want someone using
"for free".  I also don't want to worry about different
software or similar subprocs from other places conflicting
with mine. 

But, for my eRPG SDK, I use service programs.  Because I
want users to use the subprocs included in them.  And, when
I update the subprocs, I don't want the user to have to
recompile their programs using my procedures unless it's
absolutley necessary.

I don't think counting how many times it is used really
plays any role in the descision.  Knowing the how, when,
where and why the subproc will be used should determine
that.

Brad
www.bvstools.com

On Thu, 26 Aug 2004 14:43:48 -0400
 "Chris Wolcott" <CWolcott@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> A Service Program is like a DLL (Dynamic Link Library).
>  When you call a
> program, it must be located, everything about that
> program must be
> loaded into memory, resources allocated, initialized,
> etc.  Depending on
> the job environment, this can happen EVERY time it is
> called.  A service
> program loads at the same time as the calling program.
>  The calling
> program therefore takes a little longer to load, but
> every module in
> that service program is already in memory when it called,
> therefore
> saving the load time at each call.  (If a subsequent
> program in the job
> stream also calls that service program, no additional
> time is needed
> since it is already in memory.  -subject to ACTGRP, etc)
>  I was told
> that a rule of thumb was to bind directly to the module
> if it is only
> used in 3 or less programs, and to put the module in a
> service program
> if it is called by more than 3 programs.  
> 
> NOTE:  EVERY module in a service program loads at
> initialization, and if
> any of those modules refer to another service program,
> all its modules
> are also loaded in their entirety too and so on.  So keep
> your service
> programs small, with only related modules that are likely
> to also be
> called, and try not to refer to object outside of it.  
> 
>
----------------------------------------------------------------------
> 
> message: 1
> date: Thu, 26 Aug 2004 11:03:17 -0500 (CDT)
> from: Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>
> subject: Re: ServicePrograms VS normal Programs
> 
> - Portions removed - 
> 
> > What is exactly happening when an program calls
> subprocedure from 
> > service program with callP and what is happening when
> program calls 
> > another program with call and parameter list.
> 
> At a technical level?  I'm not sure that I know the
> difference. All I
> can tell you is that service program calls are much
> faster.
> 
> 
> --
> This is the RPG programming on the AS400 / iSeries
> (RPG400-L) mailing list
> To post a message email: RPG400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit:
> http://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: RPG400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the
> archives
> at http://archive.midrange.com/rpg400-l.
> 

Bradley V. Stone
BVS.Tools
www.bvstools.com