× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Perhaps this would be a good point for someone to remind us of the advantages of using service programs ...

John McKay
www.rpglanguage.com
www.mckaysoftware.ie


----- Original Message ----- From: "Mark S. Waterbury" <mark.s.waterbury@xxxxxxx>
To: "RPG programming on the AS400 / iSeries" <rpg400-l@xxxxxxxxxxxx>
Sent: Friday, September 26, 2008 2:43 PM
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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.