Re: ILE Concepts

I'm sure Jon, Scott and others will come up with some very good reasons. For me, multi-module *SRVPGMs are convenient.

If you have a team of developers, the work can be spread across a number of people (*MODULEs) then brought together in a *SRVPGM.

It might also be easier to manage change if the source and *MODULEs are more granular. (One large source member = one large *MODULE = continual changes = a monolithic approach instead of a modular approach.)

Just my 5-cents, (FWIW).

Brian.

On 01/11/2022 17:03, Birgitta Hauser wrote:

Thanks for the answers about my ILE questions ... you mostly confirmed what
I already told them (but ... as said the new guy knows everything better).

... but I have another may be silly question ... but until now nobody could
answer it in a way that I'm satisfied:

Why to bind multiple modules in a single service program?

If the functions/procedures are grouped depending on their functionality
into a source member and almost all functions are exported and the exported
ones are strongly encapsulated and only RPG is used.
Why would we need multiple modules with functions which can be grouped
together in a service program?
If the modules include functions with different functionality why we should
bind them into a single service program?
And if we are working with different programming languages, why not using a
service program for each language.

... activation time cannot be the reason, because the service programs are
bound with deferred. Also before we had deferred the activation time was
very fast, at least at this customer (and he currently has around 120
service programs with around 8000 exported functions in total).
... working with different activation groups may also cause the same service
program to be activated multiple times in the same job. The bigger the
service program the more must be loaded (multiple times) into memory

Mit freundlichen Grüßen / Best regards

Birgitta Hauser
Modernization – Education – Consulting on IBM i