what is hp-ux 64bit runtime environment?

[joe_91]

Team:

Good day. I am comparing 2 boxes, for kernel and filesets installed one test another production(which is going live this weekend). i first start by doing swlist -l bundle and there is one bundle in the test server which i DO NOT find on the production
I.
English HP-UX 64-bit Runtime Environment.

Is this a serious difference? What is this?

Please Help.

Thanks

Joe.

[Michael Steele_2]

Regarding: "...Is this a serious difference? What is this?..."

64bit refers to the word size of the O/S. Once there were 8 bit word size, then 16, now 32 is obsolete and 64 is the standard. Its an evolution in technology and memory.

Application determines the O/S word size. Are you running a Progress database on the 32 bit machine and an Oracle database on the 64 bit machine?

This is an important O/S compatibility issue that requires different version of HP-UX. And you can't mix them.

This is also a HW issue. Some older servers only support 32 bit word size. It all has to be considered.

[Pete Randall]

English HP-UX 64-bit Runtime Environment

is the Operating System itself.

What does the test box show for the O/S?


Pete

[joe_91]

Hi:

This machine primarily runs oracle database with web applications. is this a serious issu

getconf KERNEL_BITS on both the boxes says 64 bit. so i am confused.

Thanks

Joe.

[Pete Randall]

Joe,

Post the "swlist -l bundle" output from the test box, if you would, please.


Pete

[James Murtagh]

Hi Joe,

Its probably just down to the way the OS was installed. You can check which bundle on the production server the files in this bundle are in by:

Test server:

# swlist -l file

Pick a few libraries or something from this list.

Production server:

# swlist -l file | grep

You can get runtime environments for several languages, hence the need to have seperate bundles sometimes.

Regards,

James.

[S.K. Chan]

My feeling is probably not. The HPUXEng64RT bundle should show up in a installed 64-bit machine. These boxes you're comparing, are they installed the same way, ie cold-install or upgrade ? I've seen a upgrade that cause swlist to misbehaved. Anyway take a look in /var/sw/products and see if HPUXEng64RT is there or not.

[joe_91]

Hi :

I am attaching the output of swlist -l bunle for the both the boxes. Also i checked up in /var/adm/sw/products..on the test i find HPUXENG64RT, but the production box does not have it. Is this a serious issue??? Please help.

Thanks
Joe.

[joe_91]

Hi:

Actually both these boxes are cold installed(11.0) and new machines. The test is 3 months old and the production is new. both are L class.

Thanks
Joe.

[Pete Randall]

Joe,

As I said, that bundle contains the O/S itself, but since you seem to be up and running, I find it very hard to believe that the O/S is missing.

It might be interesting to try to load that bundle off the install CDs and see what it says.

If you don't get a satisfactory, definitive answer to this question, I would re-install from scratch in order to be absolutely sure that all is well.


Pete

[rick jones · Accepted solution]

In this case, 64-bit runtime means that all the libraries and commands (and the kernel) required to be able to run 64-bit, in addition to 32-bit, applications are present on the system. It also implies that the system contains PA 2.0 CPUs.

64-bit here primarily refers to the size of pointers, not necessarily the "word" size of the system.

In geek-speak, HP-UX 11 provides an "LP64" programming model. That means that variables of type "long" and of type pointer are 64-bit. Ints are still 32 bit, shorts are still 16 bits etc.

This is in contrast to the "ILP32" model for a "32-bit OS" where ints, longs and pointers are 32 bit.

The 64-bit runtime can run both 32-bit and 64-bit applications. A 32-bit runtime can only run 32-bit applications.

The difference is large, but it is only serious if you try to take an application compiled and linked on the 64-bit system and try to run it on the 32-bit system - the app will not run.. taking apps the other direction should be fine.

it does of course imply that the systems are running different kernels and such. how serious that is "depends"

[joe_91]

Hi rick;

So what do you recommned????? It lloks like from your reply that the development environment is better placed to run the apps than production right??? Please advise.

Thanks
Joe.

[rick jones]

On the surface it does seem that the development system is more "capable" (for some definition of capable centered around 64-bitness :) than the production system.

It implies that application development on the development system has to make sure it produces 32-bit applications. This is the default, but some applications, upon determining that the platofrm of compilation is capable of supporting a 64-bit application, may build a 64-bit application.

The default mode of the HP compilers, is to produce a 32-bit application using the instruction set revision of the system on which the compile takes place. So, if the compile is on a 64-bit system, that means the system is PA 2.0 (unless we are talking about IPF, which I will ass-u-me we are not) and so by default the compiler will produce a 32-bit PA 2.0 binary. That binary can run (modulo OS version compatability) on any other PA 2.0 system, 32 or 64 bit.

64-bit compilation under HP-UX is accomplished by adding a "+DD64" compiler option.

Now to make completely certain that it isn't just a swlist thing, you might try "getconf KERNEL_BITS" on both systems. I'm guessing that one will report 32 and the other 64.

As for whether or not the production system needs to be 64-bit, well, if you have applications that need/want to address more than 32-bits of address space at once then sure, production should go 64 bit. Otherwise, if the OS numbers are otherwise the same, and you watch-out for accidentally producing a 64-bit binary, it is probably OK.

I do not know about the specifics of various applications - such as say Oracle - to comment on the relative gooness of a 64-bit development system and a 32-bit production system.

[Steven E. Protter]

You don't really have much of a choice.

Your hardware probably can't run 32 bit OS anyway.

There are two levels of the Operating system above what you are currently running.

Enterprise Version, which includes more tools such as Online JFS.

Mission Critical: almost everything.

For Oracle, you are just fine, running as you are currently set up.

I would make sure the March 2003 Patches are in, along with anything Oracle recommends on top of that.

I'd check that I'm current on java patches at http://www.hp.com/go/java

Don't upgrade to java 1.4 its not certified by Oracle.

If you are migrating your database from a 32 bit platform, I've attached a migration document.

Hope this helps.

SEP

[joe_91]

Thanks!! I wonder how we were able to install the 64bitruntime env. in the test box. So does that mean the install was different OR does it really depend on the CD???

Thanks
Joe