Re: replacing binding by copy with binding by reference

Hello, Dave:

Why is your "home grown change management tool" doing all of those (needless) recompiles?

Consider the following:

1. recompile only the one *MODULE where changes were made, e.g. using
CRTRPGMOD
2. use a "cross-reference" database (outfile) to find every *PGM where
this *MODULE is bound (it sounds as though your "home grown" change
management tool already has something like this)
3. use UPDPGM to replace only the one changed *MODULE in each of the
*PGMs where it is used (bound)
4. be sure to specify REPLACE(*YES) on the UPDPGM command, so you do
not cause currently running jobs using those *PGMs to terminate
unexpectedly due to exceptions

This should be much faster than your current method, as UPDPGM is usually much faster than recompiling "the whole thing" from source each time, when you just need to update a single module.

Example:
1. we have a program named ABC that is composed of modules A, B and C.
2. we have another program named BCD that is composed of modules B, C and D.
3. you make a change to module C.
4. you can just issue:
UPDPGM PGM(mylib/ABC) MODULE(*LIBL/C)
and
UPDPGM PGM(mylib/BCD) MODULE(*LIBL/C)

and you are "all done."

Converting to using *SRVPGMs might not be a bad idea. But, this requires some care, because if you are running any of your bound *PGMs in the default activation group, once any *SRVPGMs get activated into the *DFTACTGRP of a job, there is NO WAY to _deactivate_ them, except by ending the job.

Before you embark upon a massive project to switch over to using all *SRVPGMs for your modules, you should carefully consider just how your applications currently use (even if they do not specify) "activation groups" in your applications.

You could start out by using a simple approach, by just creating one *SRVPGM for each *MODULE, but it probably makes more sense to group any related *MODULEs into a common *SRVPGM. Then, you can use UPDSRVPGM when you need to update just one module in any given *SRVPGM. Be sure to specify REPLACE(*YES) on the UPDSRVPGM command, so you do not cause any jobs currently running and using that *SRVPGM to terminate unexpectedly due to exceptions

A good "rule of thumb" recommendation is, if a module is used in more than one program, then it probably belongs in a service program (except for a few special cases).

Hope this helps,

Mark S. Waterbury
> On 6/25/2012 3:33 PM, Dave wrote:

I work in an environment that we call ILE but where not a single
service program exists. All modules are bound by copy. We don't
support having different versions of the same module in different
programs. So, when a module is modified, our home_grown CMS will
detect all utilizations of the module and recompile all programs that
use it. This is the big problem : imagine many programs all using a
procedure P1 in module M1. That procedure calls P2 in M2, which calls
P3 in M3, etc, etc. You add a call to P4 in M4 from M3/P3 for program
1 and you end up having to compile all the programs using M1! Worse,
you need to modify the binding directories just so that these unused
modules can be used to make the program compile. Gradually, more and
more programs become "related" each other, having the same module or
modules among those in their binding directories. We have now reached
the stage where a simple modification will trigger so many program
compiles that testing a new deployment is a nightmare. Developers
jostle with each other to find the time to test the deployment of
their modifications which take up to 6 hours. Then there's the manual
controlling of the large number of programs, etc.


Am I right in thinking that this problem could be rectified almost
overnight by replacing the modules by service programs? Then each
module would only exist in one place. Programs would only need
recompiling if parameters changed. Even then isn't it possible to only
compile the programs using the new parameters by using binding
language? What about limiting the impact of the changing of a file by
accessing it with one unique service program?