RE: [EXTERNAL] Re: 2 same named procedures in 2 separate service programs

Thanks for the reply Jon
I decided to bite the bullet, realizing that there may be an occasion where both of the procedures may in fact be required at the same time
So I renamed the latest created procedure and changed the programs that used this to use the renamed procedure
Fortunately - relatively speaking - it wasn't a lot of work to do

Alan Shore
E-mail : ASHORE@xxxxxxxx
Phone [O] : (631) 200-5019
Phone [C] : (631) 880-8640
'If you're going through hell, keep going.'
Winston Churchill


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxxxxxxxx] On Behalf Of Jon Paris
Sent: Thursday, May 23, 2019 11:47 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: [EXTERNAL] Re: 2 same named procedures in 2 separate service programs

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

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