I had a similar problem when running perl scripts across multiple
instances. The way I corrected it is by setting some environment
variables:
export DB2INSTANCE=<instance-owner>
export DB2DIR=/usr/IBMdb2/V7.1
export LD_LIBRARY_PATH=<instance-owner-home-dir>/sqllib/lib
After setting these variables for a particular instance/machine/version,
the scripts run without a problem.
I'm not sure if this information will be helpful in your setup, but
it might give you some ideas on how you might fix it.
Doug Carter
> 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
