×
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.
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.
midrange.com
