DSXchange

Hi

We're trying to execute a db2 command from within a sript while calling via the Before Subroutine ExecSh

This is the error thats being trapped as a result of which the job aborts

exec(): 0509-036 Cannot load program db2 because of the following errors:
0509-022 Cannot load module /usr/opt/db2_08_01/lib64/libdb2.a(shr_64.o).
0509-150 Dependent module /home/db2inst2/sqllib/lib32/libdb2osse.a(shr_64.o) could not be loaded.
0509-152 Member shr_64.o is not found in archive

Any ideas?

Thanks in advance

Looks like you are on a 64 bit UNIX server connecting to DB2.

Is you DB2 instance a 32 bit or 64 bit database?

DataStage is a 32 bit application and needs to have the links set to the 32 bit libraries.

If you are trying to run UNIX commands (db2 or db2load) then the librarys need to point to the 64 bit libraries.

gpatton wrote:Looks like you are on a 64 bit UNIX server connecting to DB2.

Is you DB2 instance a 32 bit or 64 bit database?

DataStage is a 32 bit application and needs to have the links set to the 32 bit libraries.

If you are trying to run UNIX commands (db2 or db2load) then the librarys need to point to the 64 bit libraries.

Yes the Unix box is a 64 bit system and so is the db2 instance
Do u recommend changing LIBPATH in the dsenv file to point to the 64 bit libraries for db2

Thanks in advance

The Libpath in the dsenv must point to the 32 bit libraries, because DataStage is a 32 bit application

The issue occurs when you try to execute a UNIX script connecting to DB2. In this type of script you must set the LIBPATH to the 64 bit library, because the UNIX system is seen as a 64 bit client talking to a 64 bit database.

gpatton wrote:The Libpath in the dsenv must point to the 32 bit libraries, because DataStage is a 32 bit application

The issue occurs when you try to execute a UNIX script connecting to DB2. In this type of script you must set the LIBPATH to the 64 bit library, because the UNIX system is seen as a 64 bit client talking to a 64 bit database.

Hi

Thx for the help ... a little confusion still exists
Did u mean that the LIBPATH variable should point to the 32 bit libraries in the dsenv file but and that in the script we should overide its value to point to a 64 bit library

currently this is the value of the LIBPATH variable in the dsenv file

LIBPATH=$LIBPATH:$INSTHOME/sqllib/lib32:$INSTHOME/sqllib/lib:$DB2DIR/lib:$DB2DIR
/lib32; export LIBPATH

Thnx in advance

That's correct for DataStage processes, because DataStage is a 32-bit client as far as DB2 is concerned. Environment variables for DataStage processes should be set in the dsenv script.

Other client software that you may have may require 64-bit libraries.

It's OK to have both in your shared library search path, but the right one must be found first.

Therefore, in this case, DB2's lib32 needs to precede lib.

ray.wurlod wrote:That's correct for DataStage processes, because DataStage is a 32-bit client as far as DB2 is concerned. Environment variables for DataStage processes should be set in the dsenv script.

Other client software that you may have may require 64-bit libraries.

It's OK to have both in your shared library search path, but the right one must be found first.

Thanks

Its working now!

adarsh shrinagesh wrote:Hi

We're trying to execute a db2 command from within a sript while calling via the Before Subroutine ExecSh

This is the error thats being trapped as a result of which the job aborts

exec(): 0509-036 Cannot load program db2 because of the following errors:
0509-022 Cannot load module /usr/opt/db2_08_01/lib64/libdb2.a(shr_64.o).
0509-150 Dependent module /home/db2inst2/sqllib/lib32/libdb2osse.a(shr_64.o) could not be loaded.
0509-152 Member shr_64.o is not found in archive

Any ideas?

Thanks in advance

Hi,
I have faced the same problem specified above and did the same as suggested to get rid of the problem but am still getting the same error. Can there be any possible reason of specific rights on certain directories.

Just to add a bit more, We had installed datastage on unix server quiet a time back and everything was working fine. Later on, admin disabled the dsadm user and gave the ownership of installation directories to another user in different group. I re-enabled the dsadm user and restored the group to dstage which has got all the rights. Since then I have been facing problem in connecting to a unix script which is calling DB2 in it.

So, I have a doubt that It has got to do with some permission problem.

Kindly let me know if anybody hs got any idea regarding the same.

You do not hijack others' threads, particularly not when they were resolved two years ago!

Start your own thread, and post the exact error message(s). Do not paraphrase them - use copy/paste to include the text in your post.

And please post in the correct forum - if it's a parallel job, please post there, since the diagnosis requirements will be different.