Hi everyone
I decided to rename the procedure that went in last
And change the programs that uses this procedure, to use the renamed procedure
Fortunately - it wasn't that big of a change
I seriously thought about using what Donald suggested - however - as time went on, I could see there being a need to create quite a number of "sub" binding directories, depending on what each program required
Instead - I just bit the bullet
I understand the other suggestions of using the service program name as part of the procedure - and its something we will consider
However - does anyone know if there is a way through DB2/SQL to locate all the procedure names on the system?
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
From: Alan Shore
Sent: Wednesday, May 22, 2019 9:28 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: RE: [EXTERNAL] Re: 2 same named procedures in 2 separate service programs
HI Douglas
Thanks for the suggestion
I had to read your email a couple of times before it finally sunk in what your suggestion was really talking about
CLEVER
Let me see if that will make sense
Sent via the Samsung GALAXY S(r) 5, an AT&T 4G LTE smartphone
-------- Original message --------
From: Doug Englander <denglander@xxxxxxxxxxxxxxxxxxxxxxxx<mailto:denglander@xxxxxxxxxxxxxxxxxxxxxxxx>>
Date: 5/22/19 8:40 PM (GMT-05:00)
To: midrange-l@xxxxxxxxxxxxxxxxxx<mailto:midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: [EXTERNAL] Re: 2 same named procedures in 2 separate service programs
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<mailto: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<mailto: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<mailto:support@xxxxxxxxxxxx> for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com
midrange.com
