Re: replacing binding by copy with binding by reference

Thanks, Mark.

I think it should be easy to at least change the tool to do UPDPGM if
the pgm exists already instead of crtpgm. I'll try and test that. Are
you sure that would work in all circumstances?
As for changing to srvpgm, that's what I was worried about : all those
files that stay open, global and static variables,... It looks like
we'd have to go through every job to make sure that the difference in
behaviour of the new programs does not have any effect. Should we
start by eliminating the use of the dftactgrp while still using
binding by copy?

2012/6/27 Mark S Waterbury <mark.s.waterbury@xxxxxxxxxxxxx>:

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?

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.