Re: binding directories? one big one? or smaller, specific ones?

The two conflicting modules appear to be:
*LIBL/STOADD02
LIBHTTP2/STOADD02
Since the latter is stating LIBHTTP2, the library is likely explicitly referred to somewhere. Possibly within the LIBHTTP2/HTTPAPI binding directory?
It really sounds like production source is referencing the HTTPAPI binding directory, and that binding directory is explicitly pointing to the STOADD02 module in LIBHTTP2.

-Kurt
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Gqcy
Sent: Wednesday, May 15, 2013 9:24 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: binding directories? one big one? or smaller, specific ones?

thanks for the reply...
On the compile, I was getting a CPD5D03- Definition supplied multiple
times for symbol 'xxxxxxx' Cause . . . . . : Definition STOADD02 was
found to be exported from both *MODULE object STOADD02 in library *LIBL
and *MODULE object STOADD02 in library LIBHTTP2. Recovery . . . : Try
the Create Program (CRTPGM)...


I am pretty certain that I was not referencing the binding directory in
LIBHTTP2 in anyway...




On 5/15/2013 9:13 AM, Anderson, Kurt wrote:

Hi,

Binding directories follow the standard library list scope just like any other object. Unless, of course, the reference to a binding directory is qualified. Did a source get moved to production while specifically referencing the LIBHTTP2/HTTPAPI binding directory?

I'm not sure why you're adding all of those objects to the HTTPAPI binding directory. Just to be clear - you can use more than one binding directory on a compile. So why not use both the production binding directory and the HTTPAPI binding directory?

To answer the question in your first message, we use a single binding directory for almost all of our service programs. We pretty much never create modules that are meant for more than one program. I think the only real time we have more than one module is for service programs, and in that case we create a binding directory specific to that service program.

Did the compile error actually say that it was referencing the HTTPAPI binding directory? Or was that an assumption? One thing that can happen is if you add a service program to a binding directory, and then tell that very same service program to use the binding directory, the first compile will work. The second won't because it'll try to bind to itself. I believe the error message in that situation is something similar to what you're saying in that it complains about a 'duplicate.' This may not be the case because it seems you deleted the HTTPAPI binding directory to get it to work, but I wasn't 100% sure on that.

-Kurt

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Gqcy
Sent: Tuesday, May 14, 2013 4:11 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: binding directories? one big one? or smaller, specific ones?

... I think I just had a "Ouch" moment...


I am trying to upgrade Scott's HTTPAPI...

I have the default library: LIBHTTP,
and the binding directory there (LIBHTTP/HTTPAPI)

however, I have modules and service programs I have made in our production libraries, in multiple binding directories, that need to be tested on the new code (I have made a library LIBHTTP2...)

for testing sake, each module, program, service program I test was being placed into this new library (LIBHTTP2) and if it is a module or service program, into the LIBHTTP2/HTTPAPI binding directory...

now, a programmer out of the blue is having trouble compiling an object referencing our "production" binding directory, saying a object in it, conflicts with a object in the LIBHTTP2/HTTPAPI binding directory?
I wound up deleting first the binding entries, then the modules, then the binding directory itself (the LIBHTTP2 objects) to get his program to compile???

I perceive that binding directories are broader in scope, than usual jobd/library list/ scope???







On 5/14/2013 2:32 PM, Alan Campin wrote:

So they are using the same name module in multiple programs? Ouch.

I use a single binding directory in which I only put service programs.
I use my make tool(www.think400.dk/downloads.htm) to put the
instructions in header for how to create the object. I never have
figured out how you use a binding directory to make a multiple module
program. It always comes down to have the instructions for how to make the object.

*_> CNLLSTSPLF SRCFILE(@2/@1) SRCMBR(@3) *_> DLTMOD MODULE(@5/@4)
*_> DLTPGM PGM(@5/@4) *_> CRTRPGMOD MODULE(@5/@4) SRCFILE(@2/@1)
SRCMBR(@3) +
*_> DBGVIEW(@9) OPTIMIZE(@8)
*_> CRTPGM PGM(@5/@4) MODULE(@5/@4 TG0001_M01 TG0001_M02 +
*_> TG0001_M03 TG0001_M04 TG0001_M05 TG0001_M06 TG0001_M07 +
*_> TG0001_M08 TG0001_M09 TG0001_M10 +
*_> TG0001_M50 TG0001_M51) +
*_> ENTMOD(@5/@4) BNDDIR(GPBNDDIR) OPTION(*DUPPROC) +
*_> ACTGRP(MS4)

Or

*_> DLTSRVPGM SRVPGM(@5/@4)
*_> CRTSRVPGM SRVPGM(@5/@4) +
*_> MODULE(TG_CON_M01 TG_CON_M02 TG_CON_M03 TG_CON_M04) +
*_> SRCFILE(@2/@1) SRCMBR(TG_CON_B) +
*_> TEXT('Trigger control') +
*_> ACTGRP(*CALLER) BNDDIR(GPBNDDIR QC2LE QUSAPIBD) +
*_> OPTION(*DUPPROC)



On Tue, May 14, 2013 at 1:03 PM, Gqcy<gmufasa01@xxxxxxxxx> wrote:

I need to clean up our binding directory structure here...
I am finding the same module (well, the same name anyway...) in
multiple binding directories, and no real structure to them...

What are others doing?

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

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