****************************
DB2 v8.1.6 on AIX 5.2

$ db2level
DB21085I Instance "db2inst1" uses "64" bits and DB2 code release "SQL08016"
with level identifier "02070106".
Informational tokens are "DB2 v8.1.1.56", "s040616", "U497635", and FixPak "6".
Product is installed at "/usr/opt/db2_08_01".

# bootinfo -y
64

# oslevel -r
5200-02

****************************

I have a question about some odd behavior I’m seeing when running dasupdt. After applying a fixpack, both db2iupdt and dasupdt are supposed to be run against my instance. The first runs fine, but when I run dasupdt, I get the following:

# ./dasupdt db2inst1

exec(): 0509-036 Cannot load program /home/db2inst1/das/bin/db2admin because of the following errors:

0509-150 Dependent module /home/db2inst1/das/lib64/libdb2dasapi.a(shr.o) could not be loaded.

0509-152 Member shr.o is not found in archive

exec(): 0509-036 Cannot load program /home/db2inst1/das/bin/db2admin because of the following errors:

0509-150 Dependent module /home/db2inst1/das/lib64/libdb2dasapi.a(shr.o) could not be loaded.

0509-152 Member shr.o is not found in archive

DBI1070I Program dasupdt completed successfully.



It seems to be looking for a 32bit object in the 64bit libraries. Any idea how to circumvent this behavior? I’ve extracted the shr.o from another library archive and tried putting it in libdb2dasapi.a, but it won’t let me because it constantly tells me it’s in use (even though I’ve shut down db2 and ran slibclean). Very annoying.

BTW, I noticed it's running db2admin from /bin and not from /bin64. My path includes a reference to /bin64 and no reference to /bin. Where could dasupdt be looking to find that it should execute files out of the /bin directory?

Thanks!

You run dasupdt against the Admin server, not the instance owner. This is usually dasusr1.

command sould be ./dasupdt dasusr1

(at least that is how it works in Linux).

HTH

Andy

Oops! This is true, and in my case is db2as. However, I'm still plagued with the shr.o errors:

# ./dasupdt db2as

exec(): 0509-036 Cannot load program /home/db2inst1/das/bin/db2admin because of the following errors:

0509-150 Dependent module /home/db2inst1/das/lib64/libdb2dasapi.a(shr.o) could not be loaded.

0509-152 Member shr.o is not found in archive

cp: /home/db2inst1/das/adm/db2dasrrm: Text file busy

exec(): 0509-036 Cannot load program /home/db2inst1/das/bin/db2admin because of the following errors:

0509-150 Dependent module /home/db2inst1/das/lib64/libdb2dasapi.a(shr.o) could not be loaded.

0509-152 Member shr.o is not found in archive

DBI1070I Program dasupdt completed successfully.

I've been working through a similar problem. I had installed UDB ESE 64-bit, but when I tried to start the DAS, I was receiving the shared library errors indicating that db2admin was trying to reference the wrong libraries. I discovered that editing the $DASHOME/dasprofile to reference the 64 bit binaries (instead of the 32 bit binaries) that I could get the DAS to start without a problem. From my edited dasprofile:

AddtoString PATH ${DASHOME?}/bin64
AddtoString PATH ${DASHOME?}/adm64
export PATH

LD_LIBRARY_PATH=${LD_LIBRARY_PATH:-""}
AddtoString LD_LIBRARY_PATH ${DASHOME}/lib64
AddtoString LD_LIBRARY_PATH ${DASHOME}/function64
export LD_LIBRARY_PATH

LIBPATH=${LIBPATH:-"/usr/lib:/lib"}
AddtoString LIBPATH ${DASHOME}/lib64
AddtoString LIBPATH ${DASHOME}/function64
export LIBPATH

Loren