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