Mark,
I never really thought about it this way! I definitely need to rethink
my strategy.
Thank you for this demonstration!
Sharon
-----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 / iSeries
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?
midrange.com
