× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.