Script executing DB2 command failing

Post questions here relative to DataStage Server Edition for such areas as Server job design, DS Basic, Routines, Job Sequences, etc.

Moderators: chulett, rschirm, roy

Post Reply
adarsh shrinagesh
Premium Member
Premium Member
Posts: 68
Joined: Sat Feb 05, 2005 4:59 am
Location: India

Script executing DB2 command failing

Post by adarsh shrinagesh »

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
gpatton
Premium Member
Premium Member
Posts: 47
Joined: Mon Jan 05, 2004 8:21 am

Post by gpatton »

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.
adarsh shrinagesh
Premium Member
Premium Member
Posts: 68
Joined: Sat Feb 05, 2005 4:59 am
Location: India

Post by adarsh shrinagesh »

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
gpatton
Premium Member
Premium Member
Posts: 47
Joined: Mon Jan 05, 2004 8:21 am

Post by gpatton »

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.
adarsh shrinagesh
Premium Member
Premium Member
Posts: 68
Joined: Sat Feb 05, 2005 4:59 am
Location: India

Post by adarsh shrinagesh »

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
ray.wurlod
Participant
Posts: 54607
Joined: Wed Oct 23, 2002 10:52 pm
Location: Sydney, Australia
Contact:

Post by ray.wurlod »

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.
Last edited by ray.wurlod on Sat Oct 22, 2005 4:22 pm, edited 1 time in total.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
adarsh shrinagesh
Premium Member
Premium Member
Posts: 68
Joined: Sat Feb 05, 2005 4:59 am
Location: India

Post by adarsh shrinagesh »

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!
peeyushanand
Participant
Posts: 7
Joined: Tue Jun 13, 2006 4:15 am

Re: Script executing DB2 command failing

Post by peeyushanand »

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.
ray.wurlod
Participant
Posts: 54607
Joined: Wed Oct 23, 2002 10:52 pm
Location: Sydney, Australia
Contact:

Post by ray.wurlod »

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.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Post Reply