Installing sandbox on Macintosh w/64 bit intel running LINUX

[Former Member]

Has anyone tried to install an SAP NW04s installation for use as a <b><i>portable sandbox[</i>/b] use on a Macintosh with the 64 bit Intel processors, running OS X 10.4 or higher? My goal is to have a portable SAP platform to test scenarios when I'm on the road. This is not designed to be used in a traditional customer landscape for any kind of multi-user use.

I realize this is not a supported hardware platform, but if I can install a copy of RedHat or SUSE LINUX in a VM or separate partition, it'd be interesting to see how the installation works. Anyone done it? Are there pros/cons to using RedHat vs. SUSE and which DB seems to be easiest to manage, install and maintain?

I come from a Solaris/Oracle background, so this little test is new to me. But I really want a copy of NW04s on my Macbook for mobile testing.

[markus_doehr2 · Accepted solution]

If you can get up Parallels (or any VM software) to boot a Linux distribution correctly it should work because neither the DB nor the SAP application doesn't "know", that it runs in a virtualized environment.

For the "easiest maintenance database" I'd go for MaxDB, after installation and some additional configuration steps you won't need to fiddle with it - it will just run.

--

Markus

[Former Member · Accepted solution]

Thank you. I am running VMFusion with WinXP, which works very well on the Mac. I will create 2nd VM to host LINUX. Between Red Hat and SUSE, are there any particular benefits of running one over the other in a small test environment like this?

[markus_doehr2 · Accepted solution]

Choose the one you're more familar with

I'd personally use SuSE over Redhat - but for historical reasons. The SAP kernels are compiled on SuSE hosts but they work equally on RedHat too.

Just a matter of personal choice here.

--

Markus

[manfred_stein · Accepted solution]

Hi David

I am also very much interested in your test results. You can get the 64bit NW04s for Linux/MaxDB on SDN or in www.sap.com/shop Knowledge Shop. We also have a 32bit DB2 version there. The more memory you have in your Mac the better. 2GB is minimum, more is even better. Our testdrive is not configured for minimum memory usage.

We are working on a vmware version of the 32bit DB2 NW 7.0, should be ready by TechED and Novell will have a suitable version of SLES that goes with it.

Best regards

Manfred

[Former Member · Accepted solution]

I have decided to install Solaris instead since I'm more familiar with that. So I had no problems installing Solaris 10 64 bit to the VM. Then I ran the SAP pre-requisite checker and that also was successful after a few tweaks. But when I ran sapinst, it had a problem finding the right jdk. I specified the existing 1.4.2 installation, but sapinst is looking for a java binary in an amd64 directory because it, for some reason, is detecting the CPU as an AMD64 instead of Intel X86.

I could use 1.5, but it's not officially supported. What kinds of problems might I run into if I go this route?

[manfred_stein · Accepted solution]

Hi David

Note 941595 is your friend, it cites

http://java.sun.com/j2se/1.4.2/SAPsite/download.html

there you can download the 64bit version of the 142 JDK

Manfred

[Former Member · Accepted solution]

Manfred - thank you very much for that. I'm going to install it and see how it goes.

[Former Member · Accepted solution]

The AMD64 java doesn't work on the solaris VM. The problem is that the SAPINST is finding the cpu info as this:

sun cpu isalist: amd64 pentium_prommx pentium_pro pentiummmx pentium i486 i386 i86

So then sapinst tries to find an amd64 directory when you specify a java home with this error in the logs:

Error trying to exec /usr/j2sdk1.4.2_15/bin/amd64/java

When I test the amd64 java in the solaris environment with java -verison, i get:

Error occured during initialization of VM

java/lang/NoClassDefFoundError: java/lang/object

Yet I have no problem running the 64 bit x86 solaris java executable.

So, as the CPU I'm running is intel 64 bit, I don't even think I should be putting the AMD64 jdk in there, yet the SAPINST seems to think it's AMD and looks for a jdk that is compatible.

What are the incompatibilities running java 1.5?

[markus_doehr2 · Accepted solution]

Java 1.5 will just not run.

On our box here:

bash-3.00# psrinfo -v

Status of virtual processor 0 as of: 08/30/2007 17:55:16

on-line since 07/30/2006 15:56:05.

The i386 processor operates at 3400 MHz,

and has an i387 compatible floating point processor.

Status of virtual processor 1 as of: 08/30/2007 17:55:16

on-line since 07/30/2006 15:56:13.

The i386 processor operates at 3400 MHz,

and has an i387 compatible floating point processor.

Status of virtual processor 2 as of: 08/30/2007 17:55:16

on-line since 07/30/2006 15:56:15.

The i386 processor operates at 3400 MHz,

and has an i387 compatible floating point processor.

Status of virtual processor 3 as of: 08/30/2007 17:55:16

on-line since 07/30/2006 15:56:17.

The i386 processor operates at 3400 MHz,

and has an i387 compatible floating point processor.

1. file /opt/java1.4/bin/amd64/java

/opt/java1.4/bin/amd64/java: ELF 64-bit LSB executable AMD64 Version 1, dynamically linked, stripped

JAVA_HOME must point in your case to /usr/j2sdk1.4.2_15, sapinst will choose the correct one.

AMD64 and X86_64 are synonyms, they are compatible.

Did you just install the 64bit JDK or both the 32bit and 64bit?

--

Markus

[Former Member · Accepted solution]

My results are similar, with 2CPUs at 2116Mhz

MY file java command:

ELF 32-bit

My java-version command shows mixed mode. I thought I had downloaded the 64 bit version, but I'll go check.

But either way, why does sapinst default to looking for <java_home>/bin/amd64/java instead of <java_home>/bin/java ?

[markus_doehr2 · Accepted solution]

There are two of them:

http://java.sun.com/j2se/1.4.2/download.html

That is the normal 32bit version for Solaris Intel

Sun has that "special build" of 1.4.2 in 64bit mode (for both AMD Opteron and Intel EM64T) which you get from the mention download path of Manfred.

The "default" $JAVA_HOME/bin/java is still 32bit since there are two of them. Don't get confused on the term "AMD64", that's used because that was the initial compilation flag (-xarch=amd64) because Solaris X86_64/AMD64 was released by Sun first on Opteron processors and later on Intel.

All "mixed mode" Solaris installations are organized like this:

# file /usr/lib/libc.so
/usr/lib/libc.so:       ELF 32-bit LSB dynamic lib 80386 Version 1 [SSE2 SSE MMX CMOV AMD_SYSC FPU], dynam
ically linked, not stripped, no debugging information available

# file /usr/lib/amd64/libc.so
/usr/lib/amd64/libc.so: ELF 64-bit LSB dynamic lib AMD64 Version 1, dynamically linked, not stripped, no d
ebugging information available
r

Because the J2EE engine runs ONLY on 64bit, sapinst is also ONLY looking for the 64bit binary.

--

Markus

[Former Member · Accepted solution]

Tank you for the clarification. I guess my only hangup now is that I still can't get the OS to recognize it when I do something as simple as a java -version on the 64 bit download I did from the prior link.

Running 'file java' gives me the proper ELF 64 bit LSB executable AMD64 dynamically linked...

So, why would I get the NoClassDefFound error when issuing a java -version command on that same binary? This is coming up in the sapinst log when I try to specify that 64 bit directory.

[markus_doehr2 · Accepted solution]

The reason may be, that sapinst tries to load the classes of JDK 1.5 and not the ones of the 1.4.2, additionally, there IS no $JAVA_HOME/bin/java, just $JAVA_HOME/bin/amd64/java and thus sapinst is failing.

I usually install both the 32bit version (to the $JAVA_HOME/bin/java -version running properly) and the 64bit version to run the actual software:

http://java.sun.com/j2se/1.4.2/download.html

- Download 32bit and unpack in /usr/j2sdk1.4.2_15

http://java.sun.com/j2se/1.4.2/SAPsite/download.html

- Download 64bit und unpack in the SAME directory

The try:

- stop sapinst

- [code]export JAVA_HOME=/usr/j2sdk1.4.2_15[/code]

- [code]export PATH=$JAVA_HOME/bin:$PATH[/code]

- start sapinst

With this configuration sapinst is able to do a "java -version" and get the correct version back and finally USE the 64bit out of $JAVA_HOME/bin/amd64/java to run the instance.

--

Markus

[Former Member · Accepted solution]

Markus,

I have exactly the same problems that David describes above with Solaris 10 via VMWare on a Mac.

I saw all your recommendations but I am wondering whether this can really work as long as the 64 bit java -version check returns the following error:

Error occured during initialization of VM

java/lang/NoClassDefFoundError: java/lang/object

Maybe I am missing something here but as long as this error occurs NO working 64 bit java JRE will be available.

I tried to reinstall the 64 bit JDK multiple times - no luck!

Kinda stuck here...

Thanks,

Guenther

[Former Member · Accepted solution]

Hello Markus,

I have an idea for you, but first just to make clear:

AMD64 = EM64T = x86_64 as far as ABI compatibility goes, which means that code developed for one will also run on the other (with exception to a few differences, which are documented and checked for using the CPUID command).

So, whether an AMD opteron, an Athlon 64, a Core 2, a Xeon or a Phenon it is you're using, all run the same applications, and all run the same JDK.

My idea for you is to use the blackdown JDK, it's a GPLed version that led to the sun jdk, and it's available in version 1.4.2 for AMD64/EM64T.

It's available with portage under gentoo (linux,freebsd,solaris) and with various other package managers.

Hope this helps,

Daniel

[markus_doehr2 · Accepted solution]

Did you install them into the same directory?

Markus

[Former Member · Accepted solution]

Hi Markus,

Yes I did...

I finally got it to work (SAPInst is currently in phase 44 of 50). The issue must have been with some missing Solaris patches as described in my other post at .

Thanks for your help!

Guenther