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?

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.