Re: Size of Service Program

Hi, Eric:

In OS/400, a *MODULE is never "activated" -- *MODULEs can only be used to bind into a *PGM or a *SRVPGM. Only *PGMs and *SRVPGMs can be "activated."

At the time a *SRVPGM is activated, storage is allocated for any "global" (static) variables in the *SRVPGM. When each procedure is called, dynamic storage is allocated from the runtime stack for the local storage for the procedure; allocating such a "stack frame" (or activation record) is much lass expensive than the initial activation for the entire *SRVPGM (because this will probably occur quite frequently).

There is a certain amount of overhead when a *SRVPGM is activated, because the OS/400 dynamic loader must resolve the address of each procedure that is exported from the *SRVPGM, so that they can be called indviidually from other *PGMs or *SRVPGMs (outside of the service program in which they are bound by copy . So, the more procedures you have in a *SRVPGM and that are exported, the more overhead to "activate" the *SRVPGM.

With V6R1 and above, there is a new option you can use at bind time to specify that any *SRVPGMs used by another *PGM or *SRVPGM are to be "loaded on demand" rather than all at once (when the first *PGM or *SRVPGM is loaded). On the CRTPGM or CRTSRVPGM commands (and also UPDPGM and UPDSRVPGM), the BNDSRVPGM parameter supports a new parameter, *IMMED or *DEFER, for each referenced *SRVPGM named. *IMMED is the original behavior where, when a *PGM or *SRVPGM is first activated, OS/400 would immediately load and activate any *SRVPGMs that are referenced (bound by reference) to that *PGM or *SRVPGM. *DEFER is the new option that specifies to only load that *SRVPGM when one of the procedures in that *SRVPGM is actually first called. i5/OS generates a "stub" for each procedure exported, such that when one of those procedures is called, the "stub" will cause i5/OS to activate the needed *SRVPGM, and the "glue" (stub) procedures for that *SRVPGM are then modified so that any subsequent calls will directly branch into the correct procedure entry point.

So, with V6R1 and above, your approach of "one module per service program" might actually not be a bad idea. You will only incur the overhead of activating those *SRVPGMs that are actually used in a given job execution (at runtime). This also means that the application can start up quicker, as the overhead for loading any other parts of the application can be "deferred" until later on in the job, when they are actually needed; if they are not used, they are never activated in a given job.

All the best,

Mark S. Waterbury

> On 11/8/2010 1:28 PM, DeLong, Eric wrote:

Well, as I recall, the issue as discussed in the past relates to the
ACTIVATION of the module(s) in service program. As always, when a
service program module gets activated, storage must get allocated and
initialized, which is costly. The whole idea of activation groups is to
all ONE startup cost (activation), with reuse of the already activatedi,
code as needed. If you do something silly, like making your service
program module start ACTGRP(*NEW), your huge service program could be a
performance nightmare.

Where, I'm a little fuzzy is whether all modules in a particular service
program are activated at the same time. We only use single-module
service programs here, so I haven't had to deal with this yet.

Hth,
-Eric DeLong