RE: A question about multi-module SRVPGM

Mark;

Do you have any numbers on performance for the activation of multiple service programs?

I don't either but I think that there are very very few ILE-RPG developers that would have to worry about that performance.

Take a look at IBMs service program QRNXIE which is bound to most/all RPG programs, it takes only a few minutes in DSPSRVPGM to determine that this one service program has hundreds of bound service programs, most of which have multiple modules and 10s or 100s of exported procedures.

Duane Christen

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Mark S. Waterbury
Sent: Friday, September 26, 2008 8:43 AM
To: RPG programming on the AS400 / series
Subject: Re: A question about multi-module SRVPGM

Hi, David:

Yes. And, even more important, (unless you are on V6R1 and
specify *DEFER on the BNDSRVPGM parameter), when a *SRVPGM is
activated (e.g.
"loaded"), the operating system will immediately resolve to
and activate any and all other *SRVPGMs that this one refers to.

Consider this scenario:

service program A references (invokes procedures within)
service programs B and C
service program B references (uses procedures within)
service programs D, E, and F
service program C references service programs E, F, G, and H
service program D references service programs I, J, and K
service program E references service programs L, M, N, O, and P
service program F references service programs Q, R, S, T, U and V
service program G references service programs W, X, Y and Z

As soon as service program A is activated (because the first
ILE *PGM that references it was CALLed (activated), the
following occurs:

A is activated
B is activated
D is activated
I is activated
J is activated
K is activated
E is activated
L is activated
M is activated
N is activated
O is activated
P is activated
F is activated
Q is activated
R is activated
S is activated
T is activated
U is activated
V is activated
C is activated
E is already activated, so just resolve
pointers within service program C that point to procedures within E
F is already activated, so just resolve
pointers within service program C that point to procedures within F
G is activated
W is activated
X is activated
Y is activated
Z is activated
H is activated

Also, consider that, the more *MODULEs are bound in a single
*SRVPGM, the more likely it may be that some of those
*MODULEs refer to procedures in other *SRVPGMs. Unless you
use careful planning to identify what *MODULEs refer to what
other *MODULEs, and then bind those modules together in a
single *SRVPGM, you have this "ripple" effect illustrated above.

This is why I generally recommend one *MODULE per *SRVPGM.
That way, you only activate ("load") the ones you actually
"need", especially using the V6R1 support for BNDSRVPGM(*ALL
*DEFER), which only activates a *SRVPGM when one of its
procedures is actually called.


Also, it is perfectly reasonable to bind a few modules
together into one *SRVPGM when it "makes sense"... For
example, if you have some modules:
AddEmployee, FindEmployee, UpdateEmployee and DeleteEmployee
(for example), they could all be bound together in a single
EMPLOYEE *SRVPGM, since they "encapsulate" the details of
working with the "employee"
entity, and it is likely that if you call one of these
procedures in your application, it is also likely your
application will (eventually) call one or more of the other
"related" procedures.

Does this "make sense"?

All the best,

Mark S. Waterbury

> David FOXWELL wrote:

David,

I'm starting to hesitate before posting my question.

When you say only one copy of the service program code will

be loaded into memory, would that mean the whole code for all
the functions it may have, even if the calling program only
used on of those functions?

--
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.


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit
http://www.messagelabs.com/email
______________________________________________________________________

NOTICE: This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying, or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail.