Re: Binding directory question

Hi, David:

NOTE: the following assumes you have already corrected any cases where two or more modules contain procedures with the same name.

I suggest you consider the following approach, that will allow you to gradually convert from binding all *MODULEs to using *SRVPGMs.

1. replace all of your individual binding directories with one "master" binding directory that lists all "common" modules. For now, you will continue to "bind by copy" but using this single large binding directory.

2. one by one, you will convert individual modules into service programs. For now, there will be a simple "one-to-one" relationship between each *MODULE and a *SRVPGM. For each *MODULE that you decide to convert to a *SRVPGM, perform the following steps:

(a) remove that *MODULE from the "master" binding directory (using RMVBNDDIRE)
(b) issue the CRTSRVPGM command to create the new *SRVPGM from the *MODULE, giving the *SRVPGM the same name as the module
(c) add the new *SRVPGM to the "master" binding directory (using ADDBNDDIRE)

3. When you must recompile a *MODULE, issue the CRTSRVPGM command to create a single *SRVPGM with the same name as the module, with the REPLACE(*YES) parameter specified.

With this approach, gradually, as you "touch" various *PGMs, and recompile and re-bind them, using the "master" binding directory, more and more of your programs will use "bind by reference" to the new *SRVPGMs, and less and less "bind by copy" to the *MODULEs. Eventually, all of your *MODULEs are replaced by *SRVPGMs in the binding directory, and then, as you recompile each of your programs, they will only use the *SRVPGMs.

NOTE: This does not address the issue of "activation groups" -- *SRVPGMs with ACTGRP(*CALLER) can get activated into the *DFTACTGRP, but then there is no way to deactivate them, except by ending the job. For more information about using ILE and especially about the use of Activation Groups, see Scott Klement's "ILE Concepts" presentation here:

http://www.scottklement.com/presentations/#ILECONCEPTS

Hope that helps,

Mark S. Waterbury

> David FOXWELL wrote:

Jon, I have understood the problem for quite a while now, thanks to this list.

But when you have already 2500 modules that are shared in this way, ie copied many times in many programs, how many exactly I don't know, you can't just change to service programs overnight. It's like a big ocean-going liner. 5 mile turning circle and all that.

-----Message d'origine-----
De : midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] De la part de Jon Paris
Envoyé : vendredi 23 janvier 2009 14:48
À : midrange-l@xxxxxxxxxxxx
Objet : Re: Binding directory question


On 23-Jan-09, at 6:54 AM, midrange-l-request@xxxxxxxxxxxx wrote:

All our modules are bound by copy.
When a module is modified, all programs using that module are rebound
automatically by our installation tool.
This is causing more and more headaches, ...

Without wanting to sound rude - this question is really in the category of "Doctor, doctor - it hurts when I bang my head on the wall".

Binding by copy is primarily intended to provide the best call performance in a "one caller to one callee" situation. Bind by reference (Service programs) is intended for the "Many callers one callee" situation - i.e. code reuse of the kind you describe.

So the basic solution is the same as that to the doctor question "Stop doing it" and start using service programs.

Jon Paris
www.Partner400.com
www.SystemiDeveloper.com

--
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.