Re: Service Programs / Binding Directories / *DUPPROC

Wowser! 83 modules?!

That said, will there be any great advantage in having a separate *SRVPGM for each individual *MODULE? (If I read you correctly.) Still 83 objects!

Might it work better to have multi-module *SRVPGMs?

There is very little guidance on good practice, ('cos every situation is different). However, the ILE Concepts manual does offer this,

"Try to limit the number of service programs your application uses.
This may require a service program to be created from more than one module.
The advantages are a faster activation time and a faster binding process.
There are no simple answers for the number of service programs an application
should use. If a program uses hundreds of service programs, it is probably using
too many. On the other hand, one service program may not be practical either."

Brian.

On 07/02/2018 18:00, dlclark@xxxxxxxxxxxxxxxx wrote:

"RPG400-L" <rpg400-l-bounces@xxxxxxxxxxxx> wrote on 02/07/2018 12:57:06
PM:

I would not have encountered this Brian because I would never put a
module in a binding directory.

If I remember correctly, the ability to list modules in binding
directories was intended as an easy method for building programs
from multiple modules. But few people do that - I certainly don't.

We have a program that is built from ~83 modules. That said... We
are starting a project now to split those modules out each into their own
service program (using *DEFER on the binding). Why? We need to decrease
the size of the memory footprint for this program because it is
long-running and there are ~600 jobs that execute this program as its main
process.


Sincerely,

Dave Clark