Barbara,
Thanks for the correction.
Jerry C. Adams
IBM i Programmer/Analyst
If you come to a fork in the road, take it. - Yogi Berra
--
A&K Wholesale
Murfreesboro, TN
615-867-5070
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Barbara Morris
Sent: Monday, April 16, 2012 4:09 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Prompt Service Program.
On 2012/4/16 2:43 PM, Jerry C. Adams wrote:
What release are you on? I'm still stuck at V5R1, but I thought I
read that at 6.1 or 7.1 only the procedures used were actually loaded
into memory or that there was a way to condition that.
...
Jerry, you're thinking of the ACTIVATION(*IMMED or *DEFEF) for the service
program itself. There's no way to control activation of individual
procedures in the service program.
To take advantage of deferred activation, you'd want to separate out your
infrequently called procedures into separate deferred-activation service
programs. The example that's often given is that you'd put the procedures
related to exception handling into a defer service programs, so it wouldn't
bother loading it until one of the procedures was needed.
Taking it to extremes, you _could_ put every procedure into a separate
module and service program and then activate each procedure as needed.
But in my opinion, that would be sacrificing maintainability for
performance. And it might not even improve performance, since you'd have to
factor in the cost of separately activating all those service programs. And
if they were RPG modules, you'd have to factor in the cost of having one
copy of RPG's internal "stuff" for each procedure.
No easy answers, but in general, I'd group procedures according to what
makes sense to humans, and if performance is proven to be a factor in some
particicular instance, where deferred activation might help, I'd consider
regrouping my procedures into different service programs.
--
This is the RPG programming on the IBM i / System i (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.
midrange.com
