converting existing DB2 v8.1.1.72 AIX 5.2 to 64-bit. Need info please.

[techme]

I am surprised at how little info there is on this topic. We converted
to DB2 v8.1.1.72 painlessly a few months ago. For specific reasons, we
stayed on 32-bit. Our OS is AIX 5.2 and our hardward is 64-bit P570
LPAR.

I need to convert the DB2 DB to 64-bit now. Research suggests that
this is a simple 'db2iupdt -w64 command' that will soft link our
binaries to the 64-bit cousins. All standard migration steps apply
such as take full offline backup of course. I need to understand how
this will affect our clients and what other hidden steps there may be.
Any help?

Thanks.

[Serge Rielau]

techme wrote:

I am surprised at how little info there is on this topic. We converted
to DB2 v8.1.1.72 painlessly a few months ago. For specific reasons, we
stayed on 32-bit. Our OS is AIX 5.2 and our hardward is 64-bit P570
LPAR.

I need to convert the DB2 DB to 64-bit now. Research suggests that
this is a simple 'db2iupdt -w64 command' that will soft link our
binaries to the 64-bit cousins. All standard migration steps apply
such as take full offline backup of course. I need to understand how
this will affect our clients and what other hidden steps there may be.
Any help?

Thanks.

I think the reason why there is not much info is because it really is
rather simple.....
If you have hand written external UDF or procedures (e.g. in C) it would
be good to also convert them. While running 32bit libraries in a 64 bit
environment is supported it certainly has a higher risk of breaking....

If you have SQL Procedures created prior to V8.2 I would recreate them
for the same reason (x-compiled to C)

All the 32 bit client chit-chat is handled by DRDA.

Cheres
Serge
--
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab

[techme]

Thanks. That's reassuring. Seems consistent with some of the other
sparse info that i was able to obtain.

Maybe somebody else can chime in with any other lessons learned or
gotchas.

Thanks again - Doug.

[Bernard Dhooghe]

See also the posting in comp.databases.ibm-db2:

DB2 UDB LUW 8.2:clp 32 bit connect to 64 bit engine

I can now answer the question: it is not be solved at this time.

So if using a mixed environment the LIBPATH must be taken care of.

An additional db2 command van be created setting LIBPATH:

main(argc,argv,argenv)
int argc;
char *argv[];
char *argenv[];
{ static char ar_1[]="/usr/opt/db2_08_01/lib";
static char ar_2[]="/usr/opt/db2_08_01/bin";
static char ar_3[1000000]="\0";
static char ar_4[1000000]="\0";
char *po_1;
po_1=(char *)getenv("LIBPATH");
if(po_1==(char *)NULL) putenv(ar_1);
else {strcat(ar_3,ar_1);
strcat(ar_3,po_1);
putenv(ar_3);
}
po_1=(char *)getenv("PATH");
if(po_1==(char *)NULL) putenv(ar_2);
else {strcat(ar_4,ar_2);
strcat(ar_4,po_1);
putenv(ar_4);
}
if(strcmp(argv[0],"db2")) exit(5);
execve("/usr/opt/db2_08_01/bin64/db2",argv,argenv);
}

Bernard Dhooghe
techme wrote:

I am surprised at how little info there is on this topic. We converted
to DB2 v8.1.1.72 painlessly a few months ago. For specific reasons, we
stayed on 32-bit. Our OS is AIX 5.2 and our hardward is 64-bit P570
LPAR.

I need to convert the DB2 DB to 64-bit now. Research suggests that
this is a simple 'db2iupdt -w64 command' that will soft link our
binaries to the 64-bit cousins. All standard migration steps apply
such as take full offline backup of course. I need to understand how
this will affect our clients and what other hidden steps there may be.
Any help?

Thanks.

[amurchis]

Serge Rielau wrote:

techme wrote:

I am surprised at how little info there is on this topic. We converted
to DB2 v8.1.1.72 painlessly a few months ago. For specific reasons, we
stayed on 32-bit. Our OS is AIX 5.2 and our hardward is 64-bit P570
LPAR.

I need to convert the DB2 DB to 64-bit now. Research suggests that
this is a simple 'db2iupdt -w64 command' that will soft link our
binaries to the 64-bit cousins. All standard migration steps apply
such as take full offline backup of course. I need to understand how
this will affect our clients and what other hidden steps there may be.
Any help?

Thanks.

I think the reason why there is not much info is because it really is
rather simple.....
If you have hand written external UDF or procedures (e.g. in C) it would
be good to also convert them. While running 32bit libraries in a 64 bit
environment is supported it certainly has a higher risk of breaking....

If you have SQL Procedures created prior to V8.2 I would recreate them
for the same reason (x-compiled to C)

All the 32 bit client chit-chat is handled by DRDA.

Cheres
Serge

I wanted to elaborate on the external UDF/Procedures (hereafter
"routines") statement that Serge makes. DB2 does support running 32-bit
routines in a 64-bit instance provided they are cataloged as FENCED NOT
THREADSAFE. This means that any NOT FENCED routines you have MUST BE
MIGRATED or they simply will fail to load. The default for any external
routines (JAVA the exception, which is default FENCED THREADSAFE) is
exactly this so you should be fine unless you explicitly specified
otherwise in your creation scripts. For JAVA, ensure you've installed a
64-bit JDK on your server and set the JDK_PATH correctly and you'll be
fine -- there's no need to recompile the class/JAR files.

There are actually two phases to executing a 32-bit routine. DB2 will
first attempt to load the routine's library normally, in a 64-bit FMP.
This will fail, as you cannot load a 32-bit library into a 64-bit
process. When the agent gets this failure information back, it will
then retry the processing with a 32-bit FMP, where it will succeed. The
implementation was done this way so that customers would not have to
change any routine creation scripts they had, however it does add a
significant overhead to any 32-bit routine processing.

Therefore, if you have the capability of recompiling any external
routine libraries you have to 64-bit, it is advisable from a strictly
performance standpoint to do so.