We're supporting a DB2 UDB on AIX environment, currently at V6.1. The developers are using C++ with embedded SQL, and employ a build script based on that in the Application Building Guide. When the build environment was first set up, the convention used was that each developer would build their applications under they're own ID, and not the instance owner profile. Since the build process embeds a path list into the executable of where to search for called modules, and this list did NOT include the /home/$DB2INSTANCE/SQLLIB path, they had the system administrator define a common link from /usr/lib/libdb2.a to the V6 install path libdb2.a. As part of the V7 conversion, we created a second instance on the development box, and migrated it to V7. When we try to use db2 commands in that environment, we get errors because the V6 libd2b.a is in our default path. If we break the link, the V7 instance works, but the applications stop working. The problem is, because of the path links that appear to be embedded in the executable, it appears we cannot have a common executable that can be bound to multiple instances. This is a problem since our production implementation is to simply copy the executable to the production box (which has a different instance name) and run the binds and grants. Questions: 1. Who has run into this before, and what do you do to make executables portable (build script samples would help)? 2. Do you have to relink for each instance to embed the appropriate instance path? This seems clunky for distributed systems roll-outs where our standard would call for different instance names. 3. Is there a way to keep this apparently "hardcoded" link path out of the executable, and make is use runtime path links? We've got a couple of the local IBM UDB tech support people working on answers, but any other experiences would be appreciated. Thanks, Tim Ohling/Marty Killen ===== To unsubscribe, send 'unsubscribe' to [EMAIL PROTECTED] For other info (and scripts), see http://people.mn.mediaone.net/scottrmcleod
