Re: Service Programs VS normal Programs

["Chris Wolcott" <CWolcott@xxxxxxxxxxxxxxxxxxxxxx>]

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.