Hi, Douglas:
_Some general recommendations_
1.
a *MODULE should always be "bound" in one place only -- either in a
single *PGM, if it is only used in that one program, or into a
*SRVPGM, if the procedures of that *MODULE are used in more than one
place (other *PGMs or other *SRVPGMs).
2.
never add any *MODULEs to any "binding directory" -- only add
*SRVPGMs to binding directories. This way, you can just add that
binding directory name to the H-specs in ILE RPG IV programs, and if
they use any external procedures from any of the *SRVPGMs in that
binding directory, they will be "resolved" automatically at program
create (compile or bind) time, or specify that binding directory
name when you use the CRTPGM or CRTSRVPGM command.
3. /(optional)/ use a "_naming convention_" that includes the name of
the *SRVPGM that provides (exports) any procedures, as part of the
procedure name, e.g. "SRVPGMNAME_procedureName". This requires some
additional planning, up-front, but it can help to ensure that
"mistakes" like what you encountered should not occur.
_Proposed corrective actions_
You should fix all of those cases that caused you to have to resort to
using *DUPPROC
For example, lets say you have a *MODULE named "X" that exports one or
more procedures, and somehow, someone (inadvertently or foolishly)
included that X *MODULE into two different service programs "A" and
"B". Just pck one, either "A" or "B" where you think this module "X"
should reside. Say you pick "A" ... Then, recreate the other service
program, "B", so that it no longer includes module "X".
Now, you need to check all programs and service programs to find out all
the places that "use" service program "B", which no longer includes
those procedures from "X" ...(DSPPGMREF ... *OUTFILE can help with this
task). Then, re-bind each of those *PGMs or *SRVPGMs so that they
will now "pick up" those procedures only from "the right place".
*_Summary_*
Does this "make sense"? You may also want to educate your team of
developers about the above recommendations ( at least, 1 and 2), and
this should help to prevent similar situations from recurring in the future.
All the best,
Mark S. Waterbury
> On 8/5/2014 1:07 PM, Englander, Douglas wrote:
Birgitta,
The functionality was the same, but the function was duplicated in different service programs. When the functionality needed to be changed, it was discovered the function was duplicated in multiple service programs, so the new logic was not always being called.
I did not want to bind with *DUPPROC, but that is what I had to do once all of the functions were updated, since some function names were duplicated across multiple service programs with the same function name in different service program objects.
I agree, when you need to make changes, it is difficult and very time consuming when the system is set up this way.
Doug
midrange.com
