Pro*C impacts of upgrade to Oracle 9i on HP-UX 11.0 (64-bit)

[Shawn Foran]

I am trying to assess the impacts of upgrading from:
From: Oracle 8.1.6 (32-bit) on HP-UX 11.0 (32-bit) to
-------------------->
To: Oracle 9i (64-bit) on HP-UX 11.0 (64-bit).

Oracle only delivers 9i for HP-UX 11.0 (64-bit).

The HP-UX 11.0 documentation I read indicates you can't link 32-bit and 64-bit libraries into the same executable. I assume Oracle 9i (64-bit) comes with 64-bit libraries (why else would they only offer it it on the 64-bit OS).

The issue is that our Pro*C applications is linked to several other COTS products (BEA MessageQ for example) which we currently have as 32-bit libraries (worse yet I think we have them as PA 1.1).

What I'm trying to confirm is:

* If we upgrade to Oracle 9i (64-bit), we MUST also receive 64-bit PA 2.0 libraries from our other vendor's to create the executables (i.e. BEA).

I want to make sure before I go to the other vendors that this is the case and they don't just say their product runs on the 64-bit OS (e.g. sure it's 32-bit but it run's under the 64-bit OS fine).

If the bottom line is you cannot under any circumstances link 32-bit and 64-bit libraries into the same executable then it looks like I need new libraries.

Also, I would confirmation on how I could tell the libraries are indeed 64-bit (i.e. I believe a "file" just shows PA 1.1 or PA 2.0, would it also show PA 2.0 32-bit vs. PA 2.0 64-bit or is the only issue PA 2.0)

Thanks

[Jean-Luc Oudart]

One solution is to have 32 bits client with 64 bits server.

check the link :
http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x0b1357bd90a9d611abdb0090277a778c,00.html

Hope this help

Jean-Luc

[Shawn Foran]

Thanks Jean-Luc,
It looks like this post presented several options:

Option #1: Use Oracle's 32-bit client
----------------------------
Oracle provides 32 and 64-bit client libraries (although the DBMS only runs under 64-bit).

I didn't realize this.. but it sounds like you can just link with Oracles 32-bit library (I'll have to confirm this with them).

Impact: almost no impact (except the changes associated with Oracle 9i).

Option #2: Run DBMS on HP-UX 11.0 (32-bit)
----------------------------
Oracle 9i "appears to run under the 32-bit OS?" so you just install it under HP-UX 11.0 (32-bit).

I assume the reason this works is similar to option #1 (i.e. you are linking with the a 32-bit library) although you've got to wonder how the DBMS starts up if it's a 64-bit executable?

Impact: It may work, but it sounds like Oracle won't support you.

Option #3: Upgrade everything to 64-bit
----------------------------
Obviously the best option,

Impact: it means you need to obtain 64-bit libraries from all vendors. HP says this and I assume that everyone agrees you can't mix 32-bit and 64-bit libraries?

Recommendation?
-----------------------------
I think Option #2 is too risky (even if it works).

I'll check with our COTS vendors to find out whether they have 64-bit libraries (although when we went from HP-UX 10.20 to 11.0 the impact tended to snowball because the new binaries were only available with the most recent release of their product which meant impacts due to changes in that product between releases).

If Option #3 isn't "easy), I'm tempted to stick with Option #1 -> compiling everything down to 32-bit.

One other advantage of Option #1 "may" be our ability to salvage most of our hardware (we have 20 B132's which don't support the 64-bit OS!!). If we move the physical DB's to a 64-bit machine (we have some 282's and 2240's) and keep the clients on the B132's (with the 32-bit library).

[A. Clay Stephenson]

You absolutely cannot mix 32-bit and 64-bit objects in the same link. In a few rare cases when I could not get the version of the library I needed from a vendor I had to resort to a more complicated archtecture. You can create a 32-bit version, for example, of an executable that then communicates with your main program (64-bit) via pipes or other IPCS mechanisms. On rare occasions I've had to do that to get Informix, Oracle, and Sybase to (especially in the days before ODBC) talk to each other but it's not pretty.