AutoPatch modes, arguements and options

Here are the various options for applying the patch in Oracle apps 11i and R12. ADpatch comes with lots of option that can be used, especially when we are applying the patch in production.

Modes of ADPATCH

If we talk about the mode of applying patch, there are 3 modes

1) Pre-Install Mode

Pre-install mode is used to update AD utilities before an upgrade and to apply family consolidated upgrade packs.
AutoPatch Pre-AutoInstall mode allows you to apply patches when your installation is missing database information and/or filesystem information that AutoPatch requires to run in normal mode.

Examples of when you would run AutoPatch in Pre-AutoInstall mode (and cannot run it in normal mode) include:

  • Prior to installing Oracle Applications for the first time
  • Prior to upgrading Oracle Applications to the latest release.
  • During an upgrade (to apply a bug fix that stopped your upgrade)

Applying patch in pre-install mode performs following tasks:

  • Version checking
  • File copy actions
  • Relink FND and AD executables
  • Save patch history information to file system

AutoPatch in pre-install mode will NOT:

  • Run SQL of EXEC command
  • Generate files
  • Read product driver files
  • Apply maintenance pack

To apply patch in pre-install mode, run  adpatch preinstall=y

2) Test Mode

AutoPatch provides a test mode in which it tells you everything it would have done in applying a patch, but doesn’t actually apply the patch.

To run AutoPatch in Test Mode, you must include ‘apply=no’ on the AutoPatch command line. For example:

$ adpatch apply=no

Instead of performing an action, AutoPatch indicates that it is not performing the action because “Apply=No”. In general, AutoPatch lists each file it would have copied, generated, relinked, or executed. This shows you exactly what actions it would have performed.

AutoPatch test mode works the same as normal mode, with the following exceptions:

  • It does not copy any files from your patch directory into your installation area.
  • It does not copy any files from your APPL_TOP to JAVA_TOP or OAH_TOP.
  • It does not archive any object modules into your product libraries.
  • It does not generate any forms or reports.
  • It does not relink any executables.
  • It does not run any ‘sql’ or ‘exec’ commands.
  • It does not update the release version in the database.
  • It does not update the patch history file.

AutoPatch asks you the same initial questions in test mode as in normal mode. It performs the following actions to determine what it would have done if run in normal mode:

  • Reads and validates the patch driver file.
  • Reads product file driver files.
  • Extracts object modules from your product libraries (so it can perform version checking on the object modules it extracts).
  • Performs version checking.
  • Looks in the database to determine what ‘sql’ and ‘exec’ comands it would have run.

Its a good practice to run the patch in test mode and analyze the things before applying the patch in normal mode.

3) Non-Interactive Mode

Starting in Release 11.5, you can run AutoPatch non-interactively.

Creating a defaults file

Before you can run AutoPatch non-interactively, you must first create an AutoPatch defaults file for your current environment.

Here is a simple way to create an AutoPatch defaults file for your current environment:

1. Specify defaultsfile=<New Defaults File Name> on the AutoPatch command line. The defaults file must be located under $APPL_TOP/admin/<SID>.

For example:

adpatch defaultsfile=$APPL_TOP/admin/testdb1/my_def.txt

2. Run AutoPatch up to the point where it asks you for the directory where your Oracle Applications patch has been unloaded. Then type ‘abort’ at this prompt.

3. Verify that your defaults file exists.

Once you have an AutoPatch defaults file for your current environment, you can run AutoPatch non-interactively.

Applying a single patch driver file non-interactively

Before applying any Oracle Applications patch, either interactively or non-interactively, you should read the README file (usually called readme.txt) supplied with the patch. You should also read the documentation supplied with the patch (if any).

It is possible to apply just a single patch driver file non-interactively using AutoPatch. Here is an example:

Assume the following:

  • defaults file is $APPL_TOP/admin/testdb1/def.txt
  • Applying copy driver for patch 123456, which is located in directory $APPL_TOP/patch/123456.
  • Using three parallel workers
  • AutoPatch log file name is cpy123456.log

The AutoPatch command line would be:

adpatch defaultsfile=$APPL_TOP/admin/testdb1/def.txt \
logfile=cpy123456.log \
patchtop=$APPL_TOP/patch/123456 \
driver=c123456.drv \
workers=3 \

If we dont give any of the mode as mentioned above and apply the patch simply using adpatch command then its a normal mode of patch application.

Having seen the modes of patch application, now we will see various arguements for applying patch.

1) defaultsfile
Purpose: This option is used when we are running the patch in non interactive mode. In that case we create defaults file and provide that file as an option for running patch in non-interactive mode.
Default: none. No default file read or written.

2) logfile
Purpose: This is the name of adpatch log file which it will write during patch application.
Default: none. Adpatch prompts for this value.

3) workers
Purpose: Specifies the number of workers to run. This value depends on number of CPU and other factors.
Default: none. Adpatch prompts for this value.

4) patchtop
Purpose: Top-level directory for the current patch. This is the directory after unzipping the patch. This directory will a patch number.
Default: none. Adpatch prompts for this value.

5) driver
Purpose: Name of the patch driver file. This comes with the patch and is present in patch directory.
Default – none. Adpatch prompts for this value.

6) restart
Purpose: To restart an existing session. Only valid when interactive=no is also specified
Default: No

7) localworkers
Purpose: Used in Distributed AD to specify the number of workers to be run on the current machine. If you have multi node instance (example RAC and shared APPL_TOP), then you can utilize this paramter to run the patch parallely in multiple nodes. You can start few workers on node 1, few on node 2 and so on. The way this can be done is that, you can start adpatch on one node with localworker=<some value less then total workers>. Then run adctrl on other node in distributed mode and start some mode workers. This will speed up the process and utilized the resources effectively.
Default: Value specified for workers.

8) printdebug
Purpose: To display extra debugging information.
Default: No.

Now lets consider some common options that can be used with adpatch options=<value>

1) checkfile
Purpose: To skip running exec, SQL, and exectier commands if they are recorded as already run. Indicates that Autopatch should run the command *only* if a certain file is newer than the version of it that was last run. The idea behind it is to reduce the duration of an Autopatch session by skipping actions that don’t really need to be performed. When used in the right manner, it can dramatically improve Autopatch performance, especially for big patches and/or long running actions.
Default: checkfile (use ‘nocheckfile’ to skip)

2) compiledb
Purpose: To compile invalid objects in the database after running actions in the database driver.
Default: compiledb (use ‘nocompiledb’ to skip)

3) compilejsp
Purpose: To compile out-of-date JSP files, if the patch has copy actions for at least one JSP file.
Default: compilejsp (use’nocompilejsp’ to skip)

4) copyportion
Purpose: To run commands found in a copy driver. This will copy the higher version files from patch to product top.
Default: copyportion (Use ‘nocopyportion’ to skip. Use it only when mentioned in readme of patch)

5) databaseportion
Purpose: To run commands found in a database driver. This portion includes applying the files (like sql, pls etc) to database.
Default: databaseportion (use ‘nodatabaseportion’ to skip. Use it only when mentioned in readme of patch)

6) generateportion
Purpose: To run commands found in a generate driver. This portion will generate new executable files from the copied code of patch. For example if will generate new forms files (fmx) from new .fmb files.
Default: generateportion (use ‘nogenerateporation’ to skip)

7) integrity
Purpose: To perform patch integrity checking. Tells adpatch whether to perform patch integrity checking, which verifies that the version of each file referenced in a copy action matches the version present in the patch.
Default: nointegrity (By default the integrity is not checked)

8) maintainmrc
Purpose: To maintain the MRC schema after running actions found in the database driver.
Default: maintainmrc (use ‘nomaintainmrc’ to skip)

9) autoconfig
Purpose: Tells adpatch to run Autoconfig after patch installation.
Default: autoconfig (use ‘noautoconfig’ to skip)

10) parallel
Purpose: To run actions that update the database or actions (like SQL) that generate files in parallel (like genform).
Default: parallel (use ‘noparallel’ to skip)

11) prereq
Purpose: Tells adpatch whether to perform prerequisite patch checking prior to running patch driver files that contain actions normally found in the copy driver.
Default: prereq (use ‘noprereq’ to skip)

12) validate
Purpose: To connect to all registered Oracle Applications schemas at the start of the patch. Adpatch validates the passwords for each schema.
Default: novalidate (use ‘validate’ to validate schema passwords)

Following flags can be passed to adpatch

1) hidepw
Purpose: This argument is used to hide the passwords in log files
Default: nohidepw

2) trace
Purpose: Tells the adpatch utility whether to log all database operations to a trace file
Default: notrace

3) logging
Purpose: Tells the adpatch utility whether to create indexes using the logging or nologging mode.
Default: logging

Hope this helps !!


Running Autoconfig in Test Mode

Before running the autoconfig in production to propogate your changes, its usually a good idea to run autoconfig in test mode. This will reduce the risk and you can understand the impact better. AD tool provides a script to run autoconfig in test mode. This script will create a report which will list all files & profile options that is going to change when you run AutoConfig.

Below is the sample run for the same.

(appmgr02) bin – -bash $
Enter the full path to the Applications Context file:
Enter the APPS user password:

AutoConfig is running in test mode and building diffs…

AutoConfig will consider the custom templates if present.
Using APPL_TOP location     : /slot02/appmgr/PQDC2MS1appl
Classpath                   : /local/java/jdk1.4.2_04/jre/lib/rt.jar:/local/java/jdk1.4.2_04/lib/dt.jar:/local/java/jdk1.4.2_04/lib/tools.jar:/slot02/appmgr/PQDC2MS1comn/java/

Using Context file          : /slot02/appmgr/PQDC2MS1appl/admin/PQDC2MS1/out/06190701/PQDC2MS1.xml

Context Value Management will now update the test Context file
Updating test Context file…COMPLETED

[ Test mode ]
No uploading of Context File and its templates to database.

Testing templates from all of the product tops…

Differences text report is located at: /SLOTS/slot02/appmgr/PQDC2MS1appl/admin/PQDC2MS1/out/06190702/cfgcheck.txt

Generating Profile Option differences report…COMPLETED
Generating File System differences report……COMPLETED
Differences html report is located at: /slot02/appmgr/PQDC2MS1appl/admin/PQDC2MS1/out/06190702/cfgcheck.html

Differences Zip report is located at: /slot02/appmgr/PQDC2MS1appl/admin/PQDC2MS1/out/06190702/

AutoConfig completed successfully.
The log file for this session is located at: /slot02/appmgr/PQDC2MS1appl/admin/PQDC2MS1/log/06190701/adconfig.log

Once autoconfig is run on test mode, it will generate a zip file ( as shown above. You can copy the zip file to $OA_HTML location and unzip the same. You can then view the report using following URL


Hope this helps !!

Utility to check techstack components – Oracle Applications

There is a good utility for checking all the techstack components and there versions present in e-business application. This is applicable to both 11i and R12 environments.

There is a script $FND_TOP/patch/115/bin/ on apps side which is going to fetch the versions of all components on apps side. This script can be run by giving input to $FND_TOP/patch/115/bin/ script. script takes 2 mandatory arguments, one is the script to run and another is the directory for storing log file and out file. Other then these arguments you must give context file name and location and apps password as well. Also you need to give outfile where it will create report of techstack components.

Login to apps side of your application and source the environment. Run the below command

(appmgr06) appmgr – -bash $ perl $FND_TOP/patch/115/bin/ -script=$FND_TOP/patch/115/bin/ -txktop=$APPLTMP -contextfile=$CONTEXT_FILE -appspass=apps -outfile=$OA_HTML/techstack_info.html
*** STDOUT   = /slot06/appmgr/scmc2mq0comn/rgf/scmc2mq0/TXK/txkInventory_Fri_May_16_04_01_03_2008_stdout.log

Reportfile /slot06/appmgr/scmc2mq0comn/html/techstack_info.html generated successfully.

You can access the above report file using http://(hostname.domain):(port)/OA_HTML/techstack_info.html

The report will look like this.

The report will have following information.

  • Summary of environment details
  • Inventory of HTTP Server Node
  • Inventory of Forms Server Node
  • Inventory of Concurrent Processing Server Node
  • Inventory of Administration Server Node

Similarly you can check on DB side as well

(oracle06) scmc2mq0 – -bash $ perl $ORACLE_HOME/appsutil/bin/ -script=$ORACLE_HOME/appsutil/bin/ -txktop=$ORACLE_HOME/appsutil/temp -contextfile=$CONTEXT_FILE -appspass=apps -outfile=$ORACLE_HOME/appsutil/temp/master_db.html

Hope this helps !!

Compiling JSPs in Oracle Applications

Many times we faces an issue which needs JSPs to be compiled, specially in case of development. Also for example, if some of the class files are missing then, in that case we can compile the JSPs and get the required class files.

In Oracle Applications (11i as well as R12), we have a utility called This script carries out compilation of JSPs. Below is some information regarding this script.

Oracle Apps 11i

In 11i version, this script is present in JTF_TOP/admin/scripts


(appmgr01) scripts – -bash $ ./
syntax: ./ COMMAND {ARGS}
COMMAND –compile               update dependency, compile delta
–create                rebuild entire dependency file
-delta.out <file>       update dependency, list delta to file
-dep.out <xmlfile>      update dependency, output heirarchy to file

ARGS    -s <regex>      matching condition for JSPs filenames
-p <procs>      number of parallel compilations
-log <file>     to override logfile from ojspCompile.conf
-conf <file>    to override ojspCompile.conf
–retry         retry previously failed compilation attempts
–flush         forces recompilation of all parent JSPs
–quiet         do not provide an actively running progress meter
–fast          instantly fail jsps that are *possibly* invalid

example1: –compile -s ‘jtf%’ -p 20 –retry
example2: –compile -s ‘jtflogin.jsp,jtfavald.jsp’ –flush
example3: –compile –fast –quiet


We can run the script using the above parameters. Example


(appmgr01) scripts – -bash $ ./ –compile –quiet
identifying apache_top…/slot01/appmgr/plmmtqaeora/iAS
identifying apache_config_top…/slot01/appmgr/plmmtqaeora/iAS
identifying java_home…/local/java/jdk1.4.2_04
identifying jsp_dir…/slot01/appmgr/plmmtqaecomn/html
identifying pages_dir…/slot01/appmgr/plmmtqaecomn
identifying classpath…file:///slot01/appmgr/plmmtqaeora/iAS/Apache/Jserv/etc/
auto-logging to /slot01/appmgr/plmmtqaecomn/_pages/ojsp_error.log
starting…(compiling delta)
using 8i internal ojsp ver:
including compatibility flag -whiteSpaceBetweenScriptlet
synchronizing dependency file:
enumerating jsps…15390
parsing jsp…15390
writing deplist…15390
initializing compilation:
eliminating children…12220 (-3170)
searching uncompiled…12199
translating and compiling:
searching untranslated…12199
translating jsps…12199/12199 [failed: 3] in 3m43s
compiling jsps… 51% complete: 6250/12196 ETA: 4m47s
compiling jsps…12196/12196 in 8m44s


Using parameters –compile –quiet will compile only those JSPs which are invalid and needs compilation.

If you want to compile all JSPs (irrespective of status), then you need to use –compile –flush as parameters to

Doing these will replace all the .class files in _pages directory under COMMON_TOP (which is a kind of cache for JSPs).

Also in case of 11i, automatic recompilation of JSPs are done when we access the JSP. This is the default and only behavior. So in case if you delete _pages directory under COMMON_TOP, we can always recreate the same by running or accessing the application directly.

In case we access application directly without running, the access will be little slower, since it will be doing compilation as well.

Oracle E-Business Suite R12

In case of Oracle E-Business suite R12, same script is present for compiling JSPs, but this script is present under FND_TOP/patch/115/bin directory.

Also, you cannot delete _pages directory under COMMON_TOP. Deleting this will make your application non-workable.

The reason for the same being that, in case of R12, JSPs are not compiled as and when you access them. So dynamic compilation of JSPs are not present. This is basically done to improve the performance of application system.  But in case _pages directory has been deleted, then you can recreate the same by running –compile –flush command.

Also some times, its required to have dynamic compilation of JSPs, specially in case of development environment, so that oacore will pick the latest changes. This setting can be done using a parameter in CONTEXT_FILE. The paramter name is s_jsp_main_mode.

This parameter is by default having a value of justrun, this can be changed to recompile. Once changed, you can run autoconfig and Verify that the $INST_TOP/ora/10.1.3/j2ee/oacore/application-deployments/oacore/html/orion-web.xml  has


Doing this will make new JSP to get compiled before it is shown on browser.


Metalink Note ID 458338.1

Increasing JVM heap size in E-business Suite


Many time we face the performance issue in e-business suite, specially in mid-tier. And most of the time the issue is memory. JVM fall short of memory. This post will demonstrate you about how to increase the JVM memory in middle tier.

If some one ask you a question as an APPS DBA, where will you change if you want to change the memory sizing in middle tier. Without even thinking we should say CONTEXT FILE. Thats right !!! Every thing in middle tier is controlled by CONTEXT FILE.

E-Business suite has some standard values for JVM memory that it set when you clone the instance. You can see the memory values in CONTEXT FILE as given below.

Checking the current memory sizing for mid-tier

We have following variables defined in CONTEXT FILE which defines the memory allocation to different components of application.

s_forms_jvm_start_options -> For defining memory allocation for forms.

We will have 2 elements defined for forms: forms_jvm_start_options and forms_jvm_stop_options

<forms_jvm_start_options oa_var="s_forms_jvm_start_options">-server -verbose:gc -Xmx256M -Xms64M -XX:MaxPermSize=128M -XX:NewRatio=2 -XX:+PrintGCTimeStamps -XX:+UseTLAB -XX:+UseParallelGC -XX:ParallelGCThreads=2$ORACLE_HOME/j2ee/oacore/config/java2.policy -Djava.awt.headless=true -Dhttp.webdir.enable=false</forms_jvm_start_options>
<forms_jvm_stop_options oa_var="s_forms_jvm_stop_options">-server -verbose:gc -Xmx256M -Xms64M -XX:MaxPermSize=128M -XX:NewRatio=2 -XX:+PrintGCTimeStamps -XX:+UseTLAB -XX:+UseParallelGC -XX:ParallelGCThreads=2$ORACLE_HOME/j2ee/oacore/config/java2.policy -Djava.awt.headless=true -Dhttp.webdir.enable=false</forms_jvm_stop_options>

-Xmx256M -> this mean maximum heap size is 256MB
-Xms64M  -> this mean initial heap size is 64MB
-XX:MaxPermSize -> specifies the the maximum size for the permanent generation heap

Similarly we have the following variables as well for oacore and oafm, each having start_options and stop_options

s_oacore_jvm_start_options -> For defining memory allocation for oacore.
s_oafm_jvm_start_options   -> For defining memory allocation for oafm.

The above setup if for increasing the JVM size for 1 JVM. You can also increase the number of JVM processes as well.

-bash-3.00$ grep nproc $CONTEXT_FILE
<frmsrv_nprocs oa_var=”s_frmsrv_nprocs”>1</frmsrv_nprocs>
<forms_nprocs oa_var=”s_forms_nprocs”>2</forms_nprocs>
<oacore_nprocs oa_var=”s_oacore_nprocs”>2</oacore_nprocs>
<oafm_nprocs oa_var=”s_oafm_nprocs”>1</oafm_nprocs>

If you see here we have nproc (number of JVM processes) defined for each of the component. We can even change number of JVM processes for each component. How to change these settings … keep reading !!!

Changing the JVM memory size

When you are changing the memory size, once cannot just increase the memory size. One needs to check what is the current physical memory available on this system. System I mean to say the host. Also one should see, how many environments are running on that host. Depending on these factors, you need to come up with memory available to your host.

Example in my case I have a host with 8GB RAM. I have 2 environments available on this host. So that gives me 4GB RAM for each instance (Assuming that both the instances are of similar type).
So out of 4GM of physical RAM memory, I will need 1GB for database (my SGA_TARGET is set to 1G).
We are now left with 3GB of RAM memory. Most of the issues and processing goes with oacore. So its a good idea to concentrate more on oacore and then on forms.
We can set -Xmx for s_oacore_jvm_start_options to 1024 and -Xms & -XX:MaxPermSize to 256M. That mean 1 JVM process for oacore will not consume 1G memory. We have defined 2 processes for oacore (s_oacore_nprocs parameter). So for oacore we have allocated 2G memory. We are not left with 1G memory.
Forms having max heap size (-Xmx256M) 256MB and 2 processes defined for the same. Thats makes 512MB if memory for forms. So remaining 512MB can be allocated to oafm process.

Exmaple s_oacore_jvm_start_options will look as given below.

<oacore_jvm_start_options oa_var="s_oacore_jvm_start_options">-server -verbose:gc -Xmx1024M -Xms256M -XX:MaxPermSize=256M -XX:NewRatio=2  -XX:+PrintGCTimeStamps -XX:+UseTLAB -XX:+UseParallelGC  -XX:ParallelGCThreads=2$ORACLE_HOME/j2ee/oacore/config/java2.policy -Djava.awt.headless=true -Dhttp.webdir.enable=false</oacore_jvm_start_options>

Once you make the changes in context file, run autoconfig. This will configure the memory sizing for mid-tier.


Metalink note ID: 472781.1

Generating Event level Traces in Oracle Applications

We have seen how the event traces can be generated for a database user session using Oracle Trace Utility. Now what if we need to generate the trace for some application user (either Apps 11i or E-business suite R12). In this case when a user connects to an application its very difficult to track the session.

For this reason we have a profile option, which can be set to generate trace file for any event we want within the application.

Follow the below steps for enabling the event level tracing within an application.

1) Login to application and go to “System Administrator” responsibility.

2) Navigate to “Profile -> System”

3) In the user field, enter the name of user you want to enable tracing for. This will be your application user.

4) On the profile search screen search for “Initialization SQL Statement – Custom” profile.

5) When the profile is shown you can set the value as

begin fnd_ctl.fnd_sess_ctl(”,”,’TRUE’,’TRUE’,’LOG’,’ALTER SESSION SET EVENTS=”10046 TRACE NAME CONTEXT FOREVER, LEVEL 12” tracefile_identifier=”AppsTrace_10046”’); end;

All the quotes are single quote here. You can just copy and paste the profile value.


7) In another browser window, login as the user you are going to trace and prepare to reproduce the problem

8 ) Once you are ready to reproduce the problem, go back to the Applications Forms and Save the profile change

9) Reproduce the problem

10) Back in the Applications form, set profile to null so it does not trace anymore and Save the change

11) The trace will be located in the user_dump_dest. The trace can be identified using the trace identifier we have set – “AppsTrace_10046”. If you have set some different identifier, then you can search using that key word.

Hope this helps !!

Upgrading Jinitiator for Oracle Applications 11i

Oracle JInitiator is basically available on two streams of JDK for Oracle Applications 11i customers. One stream is based on Jinitiator version 1.1.8.X version and another stream is based on 1.3.1.X version. As JDK 1.1.8 has long been de-supported by Sun, Oracle will continue to provide critical updates to Jinitiator 1.1.8 through the de-support date for Release 11.0;

Oracle strongly recommends that Oracle Applications 11i customers move to the latest certified version of JInitiator 1.3.1.x. In some cases, migration to JInitiator 1.3.1.x requires additional technology upgrades.

Many a times you might face a situation where you need to upgrade your Jinitiator version to the latest version available. Also some times users are unable to open the forms. When they click on forms, system constantly ask for jinitiator upgrade, and even after upgrading the Jinititator system keeps on asking to install the same version again and again.

This happens because of fundamental reason — Your client system is not having correct version of Jinitiator then your application is at currently. Example the situation might be that your client PC is having a Jinitiator version of where as your application expects a Jinitiator version of In that case when you click on the forms window it will automatically ask you for installation of required Jinitiator version. But note that installation of required Jinitiator version is only one time job. Next time click on forms should open the forms window correctly.

Reason for asking to install Jinitiator repeatedly is that if your application system is not having a correct version of Jinitiator then it will prompt to install the highest available version with it. If this version happens to be lower version then the required then it will repeatedly as you to install the same Jinitiator version again and again.

This problem has two solutions. First solution is to download the correct version of Jinitiator manually and install in your client PC.

Another solution is to upgrade your Jinitiator version in application system. This will put the correct Jinit exe in your application which will be downloaded and installed first time when you click on forms. With proceeding clicks it will open up the forms correctly.

This post explains about upgrading Jinitiator version of your application system.

For more details, please refer to metalink note ID 124606.1.

Upgrading JInitiator for application system

For upgrading JInitiator version of your application, you need to apply 2 patches as given below depending on your Jinitiator current version.

JInitiator Version JInitiator Patch Interop Patch 6350285 6169479 6612584 6615232

In the JInitiator patch (6350285 or 6612584) , there will be jinit*.exe. You can extract this exe file by unzipping the patch.

Once the exe file is extracted, place the exe file at $COMMON_TOP/util/jinitiator/ directory. This is the place from where the jinitiator will be downloaded in your local client PC.

After placing the exe, apply the interop patch for the respective version using the following steps.

1) Apply the patch driver in the interop patch using AutoPatch.

2) Run the script from the <patch_top>/<interop_patch_number>/fnd/patch/115/bin/ directory, against the web node of your middle tie.

The usage of the script is <jversion>

Example: 13129
(If you are upgrading to version).

The script will return the appropriate file, or prompt you for the following values:

– Location of APPSORA.env file (This is located in APPL_TOP)

– Location of Context File (echo $CONTEXT_FILE will give the location of context file)

– Password for the APPS User in the database

This will make the necessary changes to the application system and JInitiator version is now upgraded.

You can bounce the services now and access the application. This will download the correct latest JInitiator version that you have upgraded to your local PC and it will install. You will be able to access the forms as well correctly.

You can verify the JInitiator version that you have upgraded by enabling the Jinitiator’s console as per the steps given in metalink note ID 124606.1.

Hope this helps !!


Metalink note ID 124606.1

Changing Forms Servlet mode to Socket mode – E-Business Suite R12

In E-Business suite R12, by default we have forms servlet mode for opening up the forms. If we check the opmnctl for the OC4J forms services, the forms services are listed as shown below.

-bash-2.05b$ ./ status

You are running version 120.4

Checking status of OPMN managed processes…

Processes in Instance:
ias-component | process-type | pid | status
OC4J | oafm | N/A | Down
OC4J | forms | 6394 | Alive
OC4J | oacore | 881 | Alive
HTTP_Server | HTTP_Server | 1044 | Alive
ASG | ASG | N/A | Down

In servlet mode a java servlet called the Forms Listener Servlet manages the communication between the Forms Java Client and the OracleAS Forms Services. The Forms Listener Servlet communicates through the HTTP server port and does not need extra ports to handle the communication between the client and the Oracle Applicaiton Server Forms Services.

Although this is the preferred method for accessing the forms, in R12 one can also use socket mode connectivity for accessing the forms. In case of socket mode a separate port is configured for client to connect to the server. The connection is not made through Apache port. It means that in case the Apache services are down the forms services will be still up.

This may be required in the following situations:

  • Customers network topology is multinode and the forms Services are configured on a node different from the node on which Web services(Web Entry Point and Web Applications) are configured.
  • Customers constrained by network bandwidth, or machine resources may consider socket mode as an alternative to improve performance.
  • To reduce network traffic. The servlet mode uses http protocol on each transaction between a client and the Forms Server requiring the exchange of cookies and http headers which increases network traffic.
  • To reduce consumption of resources use by the JVMS needed in servlet mode architecture.

For difference between socket mode of Forms 6i and Forms 10g check metalink node ID 384241.1.

Enabling Forms Socket Mode

Changing forms servlet mode to forms socket mode is very easy. This needs running of just 1 script and bouncing the services.

Follow the below steps for changing from forms servlet mode to forms socket mode. Also note that both these modes cannot co-exits.

1) Stop all services using present in $ADMIN_SCRIPTS_HOME location.

Note that while stopping this will call script for stopping forms services. This is because the current mode is servlet mode.

2) Run the following command to enable Forms Socket Mode:

$FND_TOP/bin/ -script=ChangeFormsMode \
[-contextfile=<CONTEXT_FILE>] \
-mode=socket \
[-port=<Forms port number>] \
-runautoconfig=<No or Yes> \
-appspass=<APPS password>

Example :

$FND_TOP/bin/ -script=ChangeFormsMode \
-contextfile=$INST_TOP/appl/admin/mycontext.xml \
-mode=socket \
-port=9095 \

In this case you can get the forms port number from context file.

Make sure that autoconfig has run successfully and that it has updated the forms launcher in database.

3) start the services using present in $ADMIN_SCRIPTS_HOME

Note that this time it will use script to start the forms. This is the script for starting forms in socket mode.

Executing service control script:
/slot02/appmgr/inst/apps/SCM3R3X3/admin/scripts/ start
script returned:

You are running version 120.9.12000000.6

Starting FORMS Server in Socket Mode… exiting with status 0 check the logfile /slot02/appmgr/inst/apps/SCM3R3X3/logs/ora/10.1.2/forms/socket.log for more information …

You have new mail in /var/spool/mail/appmgr02

.end std out.

.end err out.

After converting to forms socket mode the ICX_FORMS_LAUNCHER will take below form.


Also will not list the forms process now.

-bash-3.00$ ./ status

You are running version 120.4.12000000.3

Checking status of OPMN managed processes…

Processes in Instance:
ias-component | process-type | pid | status
OC4JGroup:OC4J | OC4J:oafm | 14533 | Alive
OC4JGroup:OC4J | OC4J:oacore | 13722 | Alive
OC4JGroup:OC4J | OC4J:oacore | 13723 | Alive
HTTP_Server | HTTP_Server | 13405 | Alive exiting with status 0

Hope this helps !!


Metalink note ID 384241.1

Error while starting oacore in R12 – failure looking up ConnectionFactoryJndiName

In case of E-Business suite R12, Some times if the services of middle tier is not stopped properly then there are changes that while bringing up the services it will fail with an error code of 204. Specially this is the case with oacore and oc4j process for forms.

Usually Apache wont cause any problem while coming up.

Following error can be seen in $INST_TOP/log/ora/10.1.3/opmn/oacore_default_group_1/oacorestd.err file.


08/02/03 21:39:32 Error: <connector name=”OracleASjms” path=”OracleASjms.rar” /> will not be bootstrapped since corresponding module declaration was not found in application.xml.
08/02/03 21:39:33 *** (SEVERE) Failed to set the internal configuration of the OC4J JMS Server with: XMLJMSServerConfig[file:/slot/ems1696/appmgr/inst/apps/mz2st121_rws60050rems/ora/10.1.3/j2ee/oacore/config/jms.xml]
08/02/03 21:39:34 Error initializing server: Error initializing ejb-modules: Resource exception(OracleASjms) for MessageDrivenBean event during endpoint activation: failure looking up ConnectionFactoryJndiName:jms/XAQueueConnectionFactory: javax.resource.spi.ResourceAdapterInternalException: Looking up jms/XAQueueConnectionFactory: javax.naming.NameNotFoundException: jms/XAQueueConnectionFactory not found
08/02/03 21:42:28 Error: <connector name=”OracleASjms” path=”OracleASjms.rar” /> will not be bootstrapped since corresponding module declaration was not found in application.xml.


When we start the services, a lock file will be generated for the process and this lock file will persist till the time services are up.

This is a “safety feature” within the lightweight (pure java) OC4J Java Messaging System (JMS) implementation. The OC4J Java Messaging System creates a lock file to constrain access to a specific persistent message store to the single OC4J instance that created it.

The persistence lock file captures information about the OC4J instance that owns or previously owned the persistence store and this information includes the IP address of the owning oc4j instance. During startup if the OC4J Java Messaging System (JMS) discovers that a persistence store it has been configured to use has a lock file that it doesn’t own it will abort the startup procedure to avoid data corruption.When we bring down the services, the lock file will be removed automatically.

Now  when the services are not brought down gracefully then in that case the lock file will be still present and this file will create problem when we try to bring up the environment. Because for system, the message store is owned by some other OC4J instance and so it won’t allow any other OC4J instance to start the service.

Solution to this  problem is to remove these lock files and start the service. Lock files will be present at the below locations.

In case of OACORE services, lock file will be present at $INST_TOP/ora/10.1.3/j2ee/oacore/persistence/oacore_default_group_1 directory.

Remove all the files under this directory and start the oacore service.

In case even the forms are not opening and giving the same error, then lock files for forms can be located at $INST_TOP/ora/10.1.3/j2ee/forms/persistence/forms_default_group_1 directory and all the files under this directory can be removed. Forms services will come up, once these lock files are removed.

Hope this helps.


Metalink note ID 372412.1

Metalink note ID  398973.1

Number of users logged into Oracle E-Business Suite

You can check the number of active users currently logged into the application using the following query.

select to_char(START_TIME,’DD-MON-YYYY’) Login_Time, count(*) cnt
from fnd_logins where START_TIME > (select to_date(’25-JAN-2008 00:00:00′,’DD-MON-YYYY HH24:MI:SS’) from dual)
and login_type is not null
and end_time is null
group by to_char(START_TIME,’DD-MON-YYYY’);

LOGIN_TIME               CNT
—————– ———-
26-JAN-2008               26
25-JAN-2008              132
28-JAN-2008               13
27-JAN-2008               34

Also you can check the number of user session for the application using ICX_SESSIONS table. Use below query for checking the number of user sessions.

select ((select sysdate from dual)),(select  ‘ user sessions : ‘ || count( distinct session_id) How_many_user_sessions
from icx_sessions icx
where disabled_flag != ‘Y’
and (last_connect + decode(FND_PROFILE.VALUE(‘ICX_SESSION_TIMEOUT’), NULL,limit_time, 0,limit_time,FND_PROFILE.VALUE(‘ICX_SESSION_TIMEOUT’)/60)/24) > sysdate
and counter < limit_connects) from dual

————— ———————————————————
28-JAN-08        user sessions : 9