This page describes the steps used to install Oracle Applications 11.5.7 on SUSE Professional 8.1 and Redhat Linux 8.0.
Disclaimer: Apps 11.5.7 is not certified or supported on either SUSE Professional 8.1 or Redhat Linux 8.0. Presumably as an Oracle professional attempting the install you are already aware of this and are fully cognizant of the consequences.
This page is purely intended to be a summary of our experiences - no guarantee is given as to its accuracy - your mileage may vary. We offer it to the net simply because we would really have appreciated being able to read something like this prior to embarking on our installation process. What you read below is a distillation of many, many separate installation attempts.
For the most part, the following comments apply generically to both Redhat and SUSE. A note will be made if issues exist were found with one O/S and not another. Any reference below made to Redhat means the generically downloadable version 8.0 and any reference to SUSE refers to a purchased version of SUSE 8.1 Professional.
Both SUSE and Redhat installed very easily, found and supported the installed video card (see the SUSE caveat above) and ethernet hardware and generally worked very agreeably. We did not try to contact Redhat support since we were using the version downloaded off of their web site and in any event had no major reason to do so.
Note: To get a generic telnet daemon going on the Redhat platform you have to check the Network Servers option during the install (it isn't the default) or do it afterwards using the Package Manager. We could never figure out how to get a telnetd going with SUSE - this was another issue they ignored our emails on.
$export LD_ASSUME_KERNEL=2.2.5 $cd /usr/i386-glibc21-linux/bin $./i386-glibc21-linux-env.sh
The JRE did not seem to be necessary as the 11.5.7 install put a JRE 1.1.8 in where necessary.
We installed the j2sdk into the /usr/java/jdk1.3.1 directory. This is the default directory assumed by our 11.5.7 rapidwiz installer. We found it best not to try to put this anywhere else. We ignored the jdk.1.4.x versions available on the Sun website, operating on the theory that if that if 1.3.1 is what rapidwiz claims it wants then that is what it is going to get.
Note: We had trouble getting this RPM to installed using the traditional rpm -ivf command so rather than argue with it we just did a quick
rpm2cpio lesstif-0.93.36-1.i386.rpm | cpio -iv --makedirectoriesand copied the libXm.so.2 into /usr/X11R6/lib. Make sure your default directory is in the /tmp (or somewhere safe) area before running the rpm2cpio command because it will create an entire tree of files immediately below the current directory.
The discussion below concerns the installation of the VISION sample database. The PROD and TEST databases are not much different.
On SUSE you will probably need to enter something like export DISPLAY=:0 in the terminal session prior to running the rapidwiz installer. Also required (as root) on SUSE was an xhost +<hostname> in order to get the rapidwiz xwindow to run. Neither of these seemed to be required by Redhat.
We installed both the application tier and database tier under the user oracle so maybe that was the difference.
All other options were pretty much accepted as the default except we installed the VISION sample database rather than the PROD database the installer suggested by default.
Everything went fine until time came for the installer to re-create the control files. To do this it ran a script called adcrdb.sh. This script failed with listener problems when run by the installer but when run manually from the oracle account it worked perfectly. There was nothing we could do to convince the installer to proceed past this point - it saw the error and wanted to re-start from the beginning. There was also nothing we could do, despite repeated attempts, to convince the error to go away.
Extensive digging around on the net turned up several suggestions pointing to a deficient SEMMNS parameter (or similar). Adjusting these parameters had absolutely no effect - maybe it will for you. Here's a link telling you how to do it - the information is about half way through the document.
So what to do? The adcrdb.sh runs just fine manually and crashes from the installer. Well it's a bit of a sordid hack but if one can trick the installer into thinking it has run the adcrdb.sh script when really it has run just a simple stub which returns 0 (success) then one can run the real adcrdb.sh manually and proceed with the install. So thats what we did (sigh). Here's how to do it:
## adcrdb.sh stub printf "adcrdb stub is waiting for go.adcrdb signal" while : do if [ -f /tmp/go.adcrdb ]; then break fi echo go.adcrdb `date` sleep 10 done printf "adcrdb stub is finished" exit 0 ## adsvdcnv.sh stub printf "adsvdcnv stub is waiting for go.adsvdcnv signal" while : do if [ -f /tmp/go.adsvdcnv ]; then break fi echo adsvdcnv `date` sleep 10 done printf "adsvdcnv stub is finished" exit 0
cp /tmp/stub_adcrdb.sh /d02/oracle/visdb/8.1.7/appsutil/template/adcrdb.sh cp /tmp/stub_adsvdcnv.sh /d02/oracle/visdb/8.1.7/appsutil/template/adsvdcnv.sh
Make sure the copied stub files have exactly the same ownership and permissions as the rest of the shell scripts in the template directory.
Very shortly after this point the installer will hit the adsvdcnv.sh stub and you will see from the logs that it is waiing for a /tmp/go.adsvdcnv file. Similar to previously, run the 1_adsvdcnv.sh script and once it is complete and successful issue a touch /tmp/go.adsvdcnv command to release the stub and allow rapidwiz to proceed.
At this point one can't help but wonder how much easier life would be if only Oracle Corp would put a continue button on their installer.
The problem appears to be that the generic listener (which listens on port 1521) is started rather than the VIS listener (which listens on port 1523). This must be fixed - or lots of later stuff will topple. Issue the following commands (as the oracle user):
. /d02/oracle/visdb/8.1.7/VIS.env # set up the env, note the leading . lsnrctl stop lsnrctl start VIS
Test the connectability. If you cannot successfully connect via an oracle terminal session (having run the . VIS.env script) with a sqlplus system/manager@vis command and also via the export TWO_TASK=VIS method then things will not work later on.
Having sorted out the listener, proceed with the Tools CD's as prompted. Be aware that the installer might ask for the 9 IAS Application Server CD such and such when it really means Tools CD such and such. You cannot really get this wrong as the rapidwiz installer knows what it wants (even if it doesn't ask for it correctly) and will accept no substitutes until you get it right.
In the final completion checks we never could get the check that confirmed that the database was up to work. The database was actually fine - just the check itself didn't want to work. So we ignored it - all of the other completion checks were fine.
In the log we noticed the /d01/oracle/viscomn/admin/install/VIS/adgenjky.sh script did not execute correctly. The problem was the line jinitver=`printf "18.104.22.168" | sed 's/.//'` did not work correctly on our system (both Redhat and SUSE) replacing it with jinitver=11816 (which is really what it wanted to do) and manually re-running the file using the same command line as was recorded in the log file moved things along agreeably.
We had to manually start the Oracle Fulfillment Server. The path was wrong in the install. Run the command:
/d01/oracle/viscomn/admin/scripts/jtffmctl.sh start APPS/APPSthe installer tries to run
/d01/oracle/viscomn/admin/scripts/VIS/jtffmctl.sh start APPS/APPSwhich does not exist.
jre oracle.apps.fnd.security.AdminAppServer APPS/APPS STATUS DBC=/d01/oracle/visappl/fnd/11.5.0/secure/<DBCFileName>.dbc
http://<LinuxServerName>:8002/and the help at
You might think that if the above works then everything works? Well no, not necessarily, you have yet to login. All the above tells you is that the Apache server is happy and the JDK is workable.
http://<LinuxServerName>:8002/OA_HTML/US/ICXINDEX.htmand login as guest/oracle. Assuming that goes well try logging in as SYSADMIN/SYSADMIN. If that too goes well try navigating to the System Administrator options visible as a link far down the page under the SYSADMIN login.
If on your travels you get complaints about ActiveX security settings from your browser you'll probably want to have a look at note 125924.1. If you are getting FRM-92950 messages you might wish to view note 175332.1.
The concurrent managers are kicked off by a command like:
/d01/oracle/viscomn/admin/scripts/VIS/adcmctl.sh start APPS/APPSbut this does not seem to work (although the script returns without error) and only one FNDLIBR process appears and it soon dies. A quick look through the logs indicates that things are very unhappy and there are numerous notes to the effect that is <machine.domain> registered for concurrent processing. If you see this you have run into a bug and need to patch your apps installation. Check out this page and look up patch 2401012 (11.5.7 only) on metalink. Applying this patch and kicking off the start command shown above got all of the concurrent managers going just fine.
http://<LinuxServerName>:8002/OA_HTML/jtfqalgn.htmand there are a number of SQL tests you can run to test various things work ok. Check out notes 167000.1 and 179661.1 on metalink.