There should be a message in the log identifying the procedure in question.

"Definition supplied multiple times for symbol 'xxxxxxx' "

If you establish that the routines are absolutely identical then you may be able to use the option *DupProc to allow the program to compile. But this should only be used as a short-term solution - you need to get this fixed as others have noted.

If *DupProc does not work then the problem is buried in the references made within a binding directory. Most common cause I have seen is that people mistakenly include a *Module reference as well as a *SrvPgm reference to a SrvPgm that contains the proc. If th binding directory causes the problem the that is what you need to fix first.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On May 22, 2019, at 8:40 PM, Doug Englander <denglander@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:


To help with plan "A":

1. See if the joblog or compiler printout says which procedure is duplicated.
2. If it doesn't, then you'll have to go through each service program in the binding directories you use, looking at the exports [use DSPSRVPGM]. You will see the name of the procedure that is duplicated in multiple service programs. You mentioned you still had the compile problem after removing one of the binding directories. That may reduce the research a bit.
3. Once you locate the service programs, then locate the source of the procedure [the modules].
4. Verify that the source is identical. If the source for the procedures is different in each service program, then you'll need to investigate that too. Don't laugh, I've seen that before. Check the compiled modules too if you have the debug view set to save source.
5. Once you locate where the duplicates are, you can go on from there. You could create a one off binding directory with just the service programs you need, just to get it to compile, but that is just a band-aid approach in my view.

Hope this helps.

Doug

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

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.