About AutoCong

System configuration parameters are stored and managed by Autoconfig.

Autoconfig is a tool that simplifies and standardizes configuration management tasks in an Oracle Applications Environment.

Before the Applications context and AutoConfig were introduced, configuration management tasks could be time-consuming and prone to error, in some cases requiring manual changes to be made to several configuration files. While individual configuration files are still used in an AutoConfig-enabled environment, they play a secondary role to an XML-based repository of Applications environment information, called the context file.

By centralizing the configuration information, AutoConfig simplifies procedures for activities that range from upgrading a technology stack component to starting and stopping Applications services. Another benefit is that the various files AutoConfig employs can be updated via standard Applications patches.

There are separate context files for the application and database tiers of an Applications system.

Applications Context File :

The Applications context file, APPL_TOP/admin/<CONTEXT_NAME>.xml, is a repository for environment-specific details used by AutoConfig to configure the application tier. Information from this file is used to generate Applications configuration files and update relevant database profiles.

Information stored includes:

• Name and location of the database

• Port numbers for Forms and Web servers

• Product-specific port numbers

• Information about application tier services controlled by AutoConfig

The values of the context variables that make up the context file are in part determined by the choices you make when you run Rapid Install.

Database Context File :

The database context file,  <RDBMS_ORACLE_HOME>/appsutil/<CONTEXT_NAME>.xml, performs an equivalent role on the database tier. Information from this file is used to generate configuration files used on the database tier when AutoConfig is next run.

AutoCong Scripts :

 Key AutoConfig configuration scripts (command files on Windows) include:

• adautocfg.sh – Wrapper script that passes the name of the specific environment context file to adconfig.sh.

• adconfig.sh – Invoked by adautocfg.sh, this script is a wrapper for adconfig.pl.

• adconfig.pl – Invoked by adconfig.sh, this Perl script calls the Java API to carry out the actual configuration tasks. The relevant Java code is located in the

<JAVA_TOP> directory, either <COMMON_TOP>/java (on the application tier) or

RDBMS_ORACLE_HOME/appsutil/java (on the database tier).

AutoConfig Directories :

Directory Name                                                                      Directory Contents

<COMMON_TOP>/admin/install/<CONTEXT_NAME>    Install scripts

<COMMON_TOP>/admin/scripts/<CONTEXT_NAME>   Control scripts

<COMMON_TOP>/admin/log/<CONTEXT_NAME>        Log files

AutoCong Operation :

 As AutoConfig is used for a wide range of system configuration activities, from installation to maintenance, the following discussion of its operations is divided into several sections.

1. Context Value Management

Context Value Management (CVM) is an AutoConfig component that is used to manage the values of variables in the context file, and automate required updates to it. CVM supports updates to both the application tier and database tier context files.

CVM actions include:

• Adding new variables to a context file.

• Updating values of variables in an existing context file.

• Applying new versions of context file templates.

• Executing scripts or configuration tools that must complete before the AutoConfig engine starts, for example when generating the tnsnames.ora file. CVM is activated when the Applications context file is updated, but before the AutoConfig engine itself starts. This enables CVM to execute scripts or other tools to manipulate any required file on the file system, and allow the appropriate settings to be propagated as needed to both the file system and database. For example, it is possible toupdate values in the context file which will then be propagated to the file system.

Like the core AutoConfig components, CVM utilizes configuration files on both the

application and database tiers,

$AD_TOP/bin/adcvm.sh                                                                    Main CVM script

$AD_TOP/admin/template/adcvmat.xml Stores CVM-related data for the database tier

<RDBMS_ORACLE_HOME>/appsutil/bin/adcvm.sh                     Main CVM script

<RDBMS_ORACLE_HOME>appsutil/template/adcvmdb.xml       Stores CVM-related data for the database tier

AutoCong Files

1. Template Files

AutoConfig template files are used as the starting point for creating site-specific  configuration files.

AutoConfig evaluates the context variables in a template file, determines the actual values required, and

creates a configuration file with these values substituted. There is one template file for each configuration

file. Template files are located in the various <PROD>_TOP/admin/template directories on the application

tier, and in the <RDBMS_ORACLE_HOME>/appsutil/template directory on thedatabase tier.

Template files used by AutoConfig can be divided into the following categories:

Templates for APPL_TOP Configuration Files – These are either files requiring configuration-

specific information in the APPL_TOP, or files used to load configuration profiles into the Applications database.

Templates for Management Scripts – To run all the standard processes required by Applications,

Rapid Install creates scripts to start and stop each of these required processes. These scripts need configuration information in order to:

• Create the correct environments for each process

• Start the processes with the correct parameters

• Point the processes at the correct database instance (if applicable)

Driver Files

AutoConfig driver files are used to list the corresponding template files and locations, and specify the

commands to be executed. For example, the commands might update profile options. Driver files are

located in each <PROD>_TOP/admin/driver directory on the application tier, and in the

<RDBMS_ORACLE_HOME>/appsutil/template directory on thedatabase tier.

Configuration Files

AutoConfig configuration files, such as httpd.conf, are created as a result of AutoConfig instantiating the

corresponding template files. Configuration files contain values corresponding to the settings specified for

a particular site. After AutoConfig has been run, numerous configuration files will have been created in

various directories.

1.) Instantiation

As mentioned earlier, instantiation is the process whereby AutoConfig creates a configuration file with

contents tailored for a specific environment. AutoConfig can be used to instantiate files or scripts, and

then execute them for installation and configuration.

Examples of instantiation include:

• Instantiation of a configuration file to be used at runtime

• Instantiation of an SQL script to set profile options

• Instantiation of a shell script or Windows command file to run an SQL script in SQL*Plus

• Instantiation of scripts to start up and shut down application tier services

The adautocfg.sh script updates configuration files and profile options in the following way:

1. Instantiates template files with instance-specific values derived from the relevantcontext file

2. Copies in any customizations

3. Overwrites existing configuration files with newly instantiated ones

4. Runs SQL scripts to update database profile options.

2.) Role of the template and driver files

AutoConfig uses the various template files to determine the basic settings needed. There is one template

file for each configuration file. Different versions of the template files exist for UNIX and Windows.

The driver files list the names and locations of the files that need to have contextvariables replaced. They

also define the phases into which instantiation is divided, and specify the commands that are to be

executed for specific products. When AutoConfig runs, it cycles through the various

<PROD>_TOP/admin/driver directories looking for driver files such as adtmpl.drv, fndtmpl.drv, and

icxtmpl.drv.

Execution of Scripts

As well as its instantiation activities, AutoConfig carries out numerous other essential configuration

management tasks, by executing scripts such as the following.

Script                                                            Action

adgendbc.sh                                                 Generates the dbc file

adgenjky.sh                                                  Generates JInitiator security information

adcpnode.sh                                                 Registers nodes in the database

ssodatan.sh                                                   Associates Portal with Oracle Single Sign-On

These and other scripts are executed as applicable, depending on the requirements of the specific

Applications system.

Phases of Operation

As AutoConfig parses the driver files, it carries out a series of actions, grouped into several distinct

phases:

• INSTE8 – Instantiates AutoConfig template files to the AutoConfig configuration files specified in the

relevant template driver files.

• INSTE8_SETUP – Executes setup scripts that carry out activities not involving connection to the

database.

• INSTE8_PRF – Executes setup scripts that update profile options.

• INSTE8_APPLY – Executes setup scripts that carry out activities involving updates to the database.

• BINCPY – Copies the file mentioned from the source file to the configuration file, creating parent

directories for the latter if necessary. AutoConfig will report an error if the source file cannot be found.

• BINCPY_IGERR – Copies the file mentioned from the source file to the configuration file, creating

parent directories for the latter if necessary. AutoConfig will not report an error if the source file cannot be

found.

AutoConfig carries out these actions in the following order:

  1. All INSTE8 and BINCPY actions – Carries out all file instantiations called for during INSTE8,

INSTE8_SETUP, INSTE8_PRF and INSTE8_APPLY, and all copying from source files to target configuration files.

2. INSTE8_SETUP actions – For the files that were instantiated in Step 1, AutoConfig runs all SETUP

scripts.

3. INSTE8_PRF actions – For the files that were instantiated in Step 1, AutoConfig runs all PRF scripts.

4. INSTE8_APPLY actions – For the files that were instantiated in Step 1, AutoConfig runs all APPLY

scripts. At the end of this process, the required configuration files and profile options have been created

for the E-Business Suite installation.

Management Tasks

 Managing the Context :

Oracle Applications Manager enables you to edit the Applications  context as required. From the

Administration tab, choose AutoConfig and click Edit Parameters for the relevant context file. After

making a change to the context, you must run AutoConfig to update the relevant configuration files.

Before doing so, you should examine the proposed changes by running the adchkcfg.sh configuration

check script may on occasion be necessary to undo configuration changes. You can restore the previous

configuration by running the restore.sh utility, which enables you to roll back the changes made by an

AutoConfig run. This is achieved by utilizing the backup copies of the configuration files that are created

when AutoConfig is run.

Note: The backup files are located in

<APPL_TOP>/admin/<CONTEXT_NAME>/out/MMDDhhmm on the application tier, and

<RDBMS_ORACLE_HOME>/appsutil/out/MMDDhhmm on the

database tier, where the directory name indicates the month, day, hour and minute of the AutoConfig run.

You can restore the configuration that existed immediately before the current one by navigating to the

appropriate backup directory and running the restore.sh script. To restore an earlier configuration, you

must use the Context File History feature of Oracle Applications Manager.

Controlling the System :

AutoConfig utilizes a number of application tier control scripts, located in

<COMMON_TOP>/admin/scripts/<CONTEXT_NAME>.

Script Name                                                 Function

adstrtal.sh                                                     Starts all application tier server processes

adstpall.sh                                                    Stops all application tier server processes

adautocfg.sh                                                Runs AutoConfig

The corresponding directory on the database tier is

<RDBMS_ORACLE_HOME>/appsutil/scripts/<CONTEXT_NAME>, where control scripts allow the

database and database listener processes to be started and stopped, and AutoConfig to be run. Checking

the System.

Examining changes :

adchkcfg.sh is located in <AD_TOP>/bin on the application tier, and in

<RDBMS_ORACLE_HOME>/appsutil/bin on the database tier.

This utility generates a report that highlights differences between existing configuration files and the new

ones that AutoConfig will generate. The report is called cfgcheck.html. Running adchkcfg.sh is useful

both in carrying out a test run before a planned environment change is made, and when investigating

problems.

Listing enabled products :

adcfginfo.sh is located in <AD_TOP>/bin on the application tier, and in

<RDBMS_ORACLE_HOME>/appsutil/bin on the database tier. This utility reports if an Applications

system is AutoConfig-enabled (which will always be the case for 11.5.10). In addition, it can optionally

list the installed products that are maintained by AutoConfig.

Questions on Auto Config

Questions and Answers

1.      What is AutoConfig?

AutoConfig is a configuration tool that automates the configuration of an Oracle Applications system. The information required for configuring an Applications system is collected into a repository, called the Applications Context; there is one Applications Context for each application tier, and one for the database tier. When AutoConfig runs, it uses information from the Applications Context file to generate all configuration files and update database profiles.

2.      What is the difference between the application tier and the database tier?

Before we can answer that, let’s define a few terms in the context of the Release 11i architecture:

  • A node or machine is a computer.
  • A server is a collection of one or more computer processes that perform a specific function.
  • A tier is a logical grouping of one or more servers or computer processes.

Now let’s answer the question.

  • The application tier (also called the middle tier) consists of a number of servers, such as the concurrent processing server, web server, forms server, and administration server, that process the transactions of the Release 11i system, as well as provide communication between the desktop tier and the database tier. (Such servers are also referred to as application tier servers. Likewise, the nodes on which such servers run are also referred to as application tier server nodes.)
  • The database tier consists of the database server, which stores all the data of the Release 11i system.
  • The primary location of the files used by the application tier servers is the APPL_TOP, whereas the primary location of the files used by the database server is the Oracle8i or Oracle9i ORACLE_HOME.

3.      How can I identify the application tier and the database tier in a multi-node system?

      A node can contain one or more servers, and can therefore belong to one or more tiers.

  • In a single node system, that node belongs to both the application tier and the database tier, since all servers are contained on that single node.
  • In a multi-node system, each node contains one or more servers, and therefore belongs to one or both tiers. If the node contains any of the application tier servers, including the web server, forms server, concurrent processing server, or administration server, which means that there is an APPL_TOP on the node, then the node belongs to the application tier, and is considered an application tier server node. If the node contains the database server, which means that there is an Oracle8i or Oracle9i ORACLE_HOME and the Applications database instance on the node, then the node belongs to the database tier, and is considered a database server node.
  • Let’s analyze a common configuration where the database server and the concurrent processing server exist on one node (Node 1), and the other servers exist on a second node (Node 2). Since Node 1 contains both an application tier server (the concurrent processing server) and the database server, Node 1 belongs to both the database tier and the application tier. But since Node 2 contains only application tier servers, Node 2 belongs only to the application tier.

4.      How do I configure AutoConfig for a multi-node system?

The AutoConfig patch is applied using AutoPatch. Therefore, it must be applied to each application tier server node, which means to each node that contains an APPL_TOP.

If the database server node contains only the database server and no other servers, then you would not apply an AutoConfig patch on that node.

Once all the application tier servers have been updated by the AutoConfig patch, there is a separate process for updating the database server, which is documented in Metalink Note 165195.1. This process consists of running the admkappsutil utility on one (only one) application tier, copying the generated appsutil.zip file to the database tier and unzipping the appsutil.zip file into the RDBMS ORACLE HOME.

Example 1:
The system has two nodes.
Node 1 = administration server, concurrent processing server, database server
Node 2 = forms server, web server

Since both nodes are application tier server nodes, the AutoConfig patches need to be applied to both nodes. Once the patches are applied, you have to update the database server Node1 by running the admkappsutil utility from the APPL_TOP on Node1, copying the generated appsutil.zip to your RDBMS ORACLE_HOME on Node1 and unzipping the appsutil.zip file into the RDBMS ORACLE_HOME.

Example 2:
The system has two nodes.
Node 1 = database server
Node 2 = administration server, concurrent processing server, forms server, web server

Since Node 2 is the only application tier server node, the AutoConfig patch needs only be applied to Node 2. Once the patch is applied, you have to update the database server Node1 by running the admkappsutil utility from the APPL_TOP on Node2, copying the generated appsutil.zip to your RDBMS ORACLE_HOME on Node1 and unzipping the appsutil.zip file into the RDBMS ORACLE_HOME.

Example 3:
The system has three nodes.
Node 1 = database server
Node 2 = administration server, concurrent processing server
Node 3 = forms server, web server

Since Node 2 and Node 3 are application tier server nodes, the AutoConfig patch needs to be applied to Node 2 and Node3. Once the patches are applied, you have to update the database server Node1 by running the admkappsutil utility either from the APPL_TOP on Node1 or Node2 (it does not matter on which Node you run the admkappsutil utility), copying the generated appsutil.zip to your RDBMS ORACLE_HOME on Node1 and unzipping the appsutil.zip file into the RDBMS ORACLE_HOME.

5.      What user do I log in as to use AutoConfig in a typical multi-node system?

For nodes running Windows, there is only one user that owns both the application tier servers and the database server, so you would log in as that user.

For nodes running UNIX or Linux, if you want to configure the application tier servers, log in as the user that owns the application tier servers (sometimes referred to as the applmgr user). If you want to configure the database server, log in as the user that owns the database server (sometimes referred to as the oracle user).

6.      How do I determine if AutoConfig is enabled?

Check for the script adcfginfo.sh (adcfginfo.cmd on Windows) under <AD_TOP>/bin. If it exists, use it to check whether AutoConfig is enabled.
For the APPL_TOP:

adcfginfo.sh contextfile=<CONTEXT>

For products:

adcfginfo.sh contextfile=<CONTEXT> show=enabled

If adcfginfo.sh doesn’t exist, look in any configuration file in your APPL_TOP. If the file header contains the following, AutoConfig has been run on your instance :
################################################################
#
# AutoConfig automatically generates this file. It will be read and
# overwritten. If you were instructed to edit this file, or if you are not
# able to use the settings created by AutoConfig, refer to Metalink
# document 165195.1 for assistance.
#
################################################################

Note: If you manually changed any file containing this file header, it is no longer considered as officially AutoConfig enabled!

7.      Is AutoConfig compatible with Oracle Applications 11.5.x?

Answer:
Yes, it is compatible with all 11i releases. You can use AutoConfig to configure and maintain any Oracle Applications 11i  environment.

Release 11.5.1 – 11.5.6 (all tiers):
Apply the latest AutoConfig consolidated patch to obtain the AutoConfig utility.

Release 11.5.7 and higher (application tier):
AutoConfig is included in new Applications installations and in the associated maintenance packs.

Release 11.5.9 and higher (database tier):
AutoConfig is included in new Applications installations and in the associated maintenance packs.

Note: If you upgrade from a maintenance pack version that does not include AutoConfig to a maintenance pack version that includes AutoConfig (for example you upgrade from 11.5.3 to 11.5.10), you have to separately migrate to AutoConfig as part of the pre-upgrade process. Follow the instructions of the corresponding maintenance pack.

8.      What does the term “Context_name” mean?

The “Context_name” is the logical name for your Context. The default value for Context_name is <SID>_<hostname>. In earlier versions of AutoConfig the default was set to <SID>.

9.      What are the basic components of AutoConfig?

Components Location Description
Applications Context On the application tier:
<APPL_TOP>/adminOn the database tier:
<RDBMS ORACLE_HOME>/appsutil
An XML repository (<Context_name>.xml) contains information specific to that Applications instance. Can be updated by running the Context Editor.
Do not manually update this file!
AutoConfig Template Files On the application tier:
<PROD_TOP>/admin/template
For example:
<AD_TOP>/admin/template
<FND_TOP>/admin/templateOn the database tier:
<RDBMS ORACLE_HOME>/appsutil/template
Include named tags which are replaced with instance-specific information from the Applications Context. There is one template file for each configuration file.
For example:
apps_nt.conf
apps_ux.conf
AutoConfig File Driver On the application tier:
<PROD_TOP>/admin/driver
For example:
<AD_TOP>/admin/driver/adtmpl.drv
<FND_TOP>/admin/driver/fndtmpl.drvOn the database tier:
<RDBMS ORACLE_HOME>/appsutil/template
Used by AutoConfig to list the AutoConfig Template Files, their destination locations, and the commands to be executed, for example, the commands to update profile options. Every Product Top contains its own AutoConfig File Driver.
AutoConfig Scripts On the application tier:
<AD_TOP>/binOn the database tier:
<RDBMS ORACLE_HOME>/appsutil/bin
Provide a simplified
interface to the AutoConfig APIs.
For example:
adautocfg.sh / adautocfg.cmd
adconfig.sh / adconfig.cmd

10.  What are the different AutoConfig scripts and what do they do?

The scripts are listed in the following table.

Note: .sh scripts are for UNIX users and .cmd scripts are for Windows users.
Scripts Location Description
adautocfg.shadautocfg.cmd On the application tier:
<COMMON_TOP>/admin/scripts/
<Context_name>On the database tier:
<RDBMS ORACLE_HOME>/appsutil/
scripts/ <Context_name>
A wrapper script that calls adconfig.sh/ adconfig.cmd. Instantiates template files with values specific to the instance (taken from the Applications Context). Updates configuration files and profile options.
adconfig.shadconfig.cmd On the application tier:
<AD_TOP>/binOn the database tier:
<RDBMS ORACLE_HOME>/appsutil/bin/
A wrapper script that calls adconfig.pl. In earlier versions of AutoConfig adconfig.sh/adconfig.cmd used to call the Java API to start AutoConfig.
adconfig.pl On the application tier:
<AD_TOP>/binOn the database tier:
<RDBMS ORACLE_HOME>/appsutil/bin
A wrapper script that calls the Java API to start AutoConfig.
adbldxml.shadbldxml.cmd On the application tier:
<AD_TOP>/binOn the database tier:
<RDBMS ORACLE_HOME>/appsutil/bin
Creates the Applications Context File. Before running this script, you need to source the environment.
On the application tier:
Source APPS<Context_name>.env (or APPSORA.env if APPS<Context_name>.env doesn’t exist).
On the database tier:
Source <Context_name>.env
adchkcfg.shadchkcfg.cmd On the application tier:
<AD_TOP>/binOn the database tier:
<RDBMS ORACLE_HOME>/appsutil/bin
Generates a report that highlights differences between the original config files and AutoConfig-generated config files. The report is named cfgcheck.html. It is located under:
On the application tier:
<APPL_TOP>/admin/
<Context_name>/out/<MMDDhhmm>
On the database tier:
<RDBMS ORACLE_HOME>/appsutil/out/
<Context_name>/<MMDDhhmm>

AutoConfig pre-requisites

11.  Do I need to upgrade to Apache 1.3.12s?

If you are applying the AutoConfig patch to an instance created with a Rapid Install version lower than Release 11.5.5, upgrade to Apache 1.3.12s.

Refer to Metalink Document 161779.1 on OracleMetalink.

Note: Rapid Install for versions 11i7 and higher installs Oracle HTTP Server 1.3.19 from iAS 1.0.2.2

The Context file

12.  How will the adbldxml utility name the Applications Context file it generates?

When adbldxml generates the Context file, it first checks for the existence of an Applications Context file conforming to specific requirements in the <APPL_TOP>/admin directory on the application tier and in the <RDBMS ORACLE_HOME>/appsutil directory on the database tier.
If an xml file exists, adbldxml creates the Applications Context file using the same name.
Specific requirements are:

  • The Context file refers to the hostname for which we generate the file.
  • The Context file refers to the Database SID for which we generate the file.

The default name for the Context file is <Context_name>.xml.

13.  How can I make changes to the Applications Context file?

Go to the OAM Login page. Sign in and navigate to Site Map. Click on AutoConfig. Use this link to update your Applications Context file.

Note: Manually editing the Applictions Context file is not supported. Many context variables have dependencies between each other. The OAM AutoConfig resolves all these dependencies when changing the value of a variable. By manually editing the Applications Context file you will bring the data into an inconsistent state.

14.  I want to execute the adbldxml utility on a fresh RDBMS Oracle Home. How can I build the Context file, when the database environment file is not present?

The adbldxml utility requires the following environment variables to be set:

  • ORACLE_HOME
  • ORACLE_SID (LOCAL on Windows)
  • TNS_ADMIN

Set the variables according to your instance. For example:

  • On UNIX
    export ORACLE_SID=PROD
  • On Windows
    set LOCAL=PROD

15.  I was instructed to change the value of the context variables s_adperlprg and s_perl5lib. How can I achieve that?

Apply the latest AutoConfig patch, then perform the following steps depending on your use case:

  • You were instructed to use a certain perl version. You have perl and its libraries installed in the perl standard location for your os (e.g. /usr/lib/perl5 on Linux) and perl is in your PATH:
  1. unset PERL5LIB
  2. perl $AD_TOP/bin/adconfig.pl
  3. Source the environment file (APPS<Context_name>.env)
  4. Review your Applications Context file; s_adperlprg and s_perl5lib will now point to your system perl location.
  • You were instructed to use a certain perl version. You installed perl and its libraries into a custom – non perl standard location (e.g. perl is installed at /u03/myperl/bin and the perl libraries at /u03/myperl/lib).
  1. PERL5LIB=<location of the new PERL5LIB that you want to use>
  2. export PERL5LIB
  3. <location of the new perl you want to use> <AD_TOP>/bin/adconfig.pl
  4. Source the environment file (APPS<Context_name>.env)
  5. Review your Applications Context file; s_adperlprg and s_perl5lib will now point to your customized perl location.

Example:

  • PERL5LIB=/u03/myperl/lib/5.00503:/u03/myperl/lib/site_perl/5.005
  • export PERL5LIB
  • /u03/myperl/bin/perl $AD_TOP/bin/adconfig.pl

AutoConfig will update the context variables in the context file accordingly. After the AutoConfig run subsequent utilities and tools can use the context variables s_adperlprg and s_perl5lib.

Running AutoConfig

16.  When should I run AutoConfig?

You should run AutoConfig in the event of the following cases:

  • You did updates to your Applications Context file.
  • An Oracle Metalink Note instructs you to run AutoConfig as part of an upgrade, migration, cloning and/or configuration process.
  • The Readme of an Oracle patch instructs you to run AutoConfig after the application of the patch.
  • You apply any ADX Product patch.
Note: When you have AD.I or higher applied on your system, then adpatch will automatically invoke AutoConfig if the patch that you apply requires AutoConfig to run.

17.  Which files / profile options get changed when I run AutoConfig?

Run the adchkcfg utility to get an html report that lists all the files and profile options that get changed when you run AutoConfig.

If you have AD.I or higher applied and you want to see the list of files and profile options that will get changed when adpatch is run, then run adpatch with the apply=no option before applying the patch.

18.  Where is the log file located that AutoConfig creates?

The log file that AutoConfig creates is located at:

On the application tier:
<APPL_TOP>/admin/<Context_name>/log/<MMDDhhmm>/adconfig.log

On the database tier:
<RDBMS ORACLE_HOME>/appsutil/log/<Context_name>/<MMDDhhmm>/adconfig.log

where: <MMDDhhmm> = (month, day, hour, and minute of the AutoConfig run)

19.  Which directories based on the Context_name will AutoConfig create?

AutoConfig creates the following directories based on the Context_name:

Install Scripts : <COMMON_TOP>/admin/install/<Context_name>
Control Scripts : <COMMON_TOP>/admin/scripts/<Context_name>
Log files : <COMMON_TOP>/admin/log/<Context_name>

Beginning with Release 11.5.7, Oracle Applications comes with the modified directory structure.

20.  I see multiple directories under <COMMON_TOP>/admin/scripts – which one do I use?

Previously, AutoConfig generated the directory <SID> in <COMMON_TOP>/admin/scripts. To provide support for a shared APPL_TOP, AutoConfig now creates the directory <SID>_<hostname>.
If your system contains both directory names, use the scripts under <SID>_<hostname>. You can safely delete directories named <SID>, after backing them up.

21.  How can I roll back an AutoConfig session?

All backup configuration files from each AutoConfig session are stored in:
On the application tier:
<APPL_TOP>/admin/<Context_name>/out/<MMDDhhmm>/

On the database tier:
<RDBMS ORACLE_HOME>/appsutil/out/<Context_name>/<MMDDhhmm>/

where: <MMDDhhmm> = (month, day, hour, and minute of the AutoConfig run)

You can run restore.sh (Unix) or restore.cmd (Windows) to roll back an AutoConfig session.

22.  How does AutoConfig know which scripts to create for service controls?

The following variables in the Applications Context File let AutoConfig know which scripts to create:

Context Variable Action
s_isAdmin If set to Yes, create administration service scripts
s_isConc If set to Yes, create concurrent processing and reports service scripts
s_isWeb If set to Yes, create web service scripts
s_isForms If set to Yes, create forms service scripts

The variables are set according to your configuration when you create the Applications Context file:

Single-node system: All the service control scripts are present on the same node. Therefore, all variables are set to “YES” in the Applications Context file.

Multi-node system:

Example

Node 1 = forms server, web server
Node 2 = concurrent processing server, administration server, database server

On Node 1 only the forms and web service control scripts are created. On Node 2 only the admin and concurrent processing service control scripts are created. The Applications Context files contain the following values:

Context Variable Node 1 Node 2
Value Value
s_isAdmin NO YES
s_isConc NO YES
s_isWeb YES NO
s_isForms YES NO

23.  How does AutoConfig know what application tier node type the APPL_TOP supports?

The AD Utilities such as AutoPatch and AD Administration patch and maintain files based on the application tier node type that the APPL_TOP supports. The following variables in the Applications Context file define which files are patched and maintained for the APPL_TOP:

Context Variable Action
s_isAdAdmin If set to Yes, the APPL_TOP contains binaries and scripts used to maintain the Applications system.
s_isAdConc If set to Yes, the APPL_TOP can be used to provide the CP and Reports services. All binaries, scripts, reports and other files related to these services exist in the APPL_TOP.
s_isAdWeb If set to Yes, the APPL_TOP contains the necessary files to provide Oracle HTTP services
s_isAdForms If set to Yes, the APPL_TOP contains the necessary files to provide Forms services

The variables are set according to your configuration when you create the Applications Context file:

Single-node system: All the application tier types are present on the same node and there is only one APPL_TOP. All variables are set to “YES” in the Applications Context file.

Multi-node system sharing the same APPL_TOP: A shared APPL_TOP contains all the necessary software components to run any service. All variables are set to “YES” in the Applications Context files sharing the APPL_TOP.

Multi-node system, where every node has a separate APPL_TOP:

Example:

Node 1 = forms server, web server
Node 2 = concurrent processing server, administration server, database server

Every node has its own APPL_TOP that only patches and maintains the files specific to the node. The Applications Context files contains the following values:

Context Variable Node 1 Node 2
Value Value
s_isAdAdmin NO YES
s_isAdConc NO YES
s_isAdWeb YES NO
s_isAdForms YES NO

Customizations

24.  What do I do when a patch or Oracle documentation instructs me to manually modify an AutoConfig-maintained file?

Contact Oracle Support to incorporate the necessary changes in the AutoConfig templates:

  1. Identify the patch or the note that is requesting the manual change.
  2. Log a Service Request with Oracle Support, providing the same information.

Patching AutoConfig

25.  How do I get the latest changes to AutoConfig?

Updates to AutoConfig are delivered in the ADX product patch. The latest patch at the time of this writing are patch number 3453499.

26.  How do I apply the latest AutoConfig patch?

Perform the following steps in the order listed:

  • Review the pre-requisites as documented in Metalink Note 165195.1.
  • Apply the AutoConfig patch
    Update the Oracle Applications file system with the AutoConfig files by applying patch 3453499. to all application tier nodes in the Applications instance.
  • Copy AutoConfig to the RDBMS ORACLE_HOME
    If you enabled AutoConfig on the Database Tier, update the RDBMS ORACLE_HOME file system with the AutoConfig files by performing the following steps:
  • On the Application Tier (as the APPLMGR user):
  • Log in to the APPL_TOP environment (source the environment file)
  • Create appsutil.zip file
    perl <AD_TOP>/bin/admkappsutil.pl
  • This will create appsutil.zip in $APPL_TOP/admin/out .
  • On the Database Tier (as the ORACLE user):
  • Copy or FTP the appsutil.zip file to the <RDBMS ORACLE_HOME>
  • cd <RDBMS ORACLE_HOME>
    unzip -o appsutil.zip
  • Run AutoConfig on the Database Tier
    If you enabled AutoConfig on the Database Tier, run AutoConfig on the database tier node.
Attention: The database server must remain available during the AutoConfig run. All the other database tier services should be shut down.
  • Run AutoConfig on the Application Tiers
    Run AutoConfig on all application tier nodes.
Attention: The database server must remain available during the AutoConfig run. Only the application tier servers should be shut down.

27.  What mechanism is used to generate the tnsnames.ora file?

In ADX.D and earlier, AutoConfig instantiates the tnsnames.ora file based on an AutoConfig template. To support enhanced configuration scenarios (for example RAC), the adgentns.pl script dynamically generates the tnsname.ora file. It generates the tnsnames.ora based on the information in the Net Services Topology Data Model. The adgentns.pl script was introduced with ADX.E. Refer to the following matrix to understand when tnsnames.ora is generated from a template or from the adgentns.pl script:

PRE ADX.E ADX.E and higher
FND_NODES.NODE_ID column is present FND_NODES.NODE_ID column is not present TXK.G and FND_NODES.NODE_ID column is present Exceptions like database not available
AutoConfig on database tier template adgentns.pl template adgentns.pl template
AutoConfig on application tier template adgentns.pl template template template

Database connectivity

28.  Should the database server remain available during the AutoConfig run?

Yes. The database server and the database listener must remain available during the AutoConfig run. This is true when running AutoConfig on the application tier, as well when running AutoConfig on the database tier. If you run AutoConfig on the application tier, then the 806 database listener must remain available also.

29.  What is the use of the context variable s_apps_jdbc_connect_descriptor?

The s_apps_jdbc_connect_descriptor stores the connect string for jdbc connections. All jdbc connections are done using this context variable. The value for this context variable is generated by AutoConfig.

When the value is reset (empty), AutoConfig tries to connect to the database using the s_dbSid, s_dbhost and s_dbport context variables.

30.  When do I need to reset (empty) the context variable s_apps_jdbc_connect_descriptor?

You should reset the value for s_apps_jdbc_connect_descriptor to an empty value (” “), when one of the following value changes:

  • Database Host
  • Database Port

31.  What steps do I need to follow to maintain my database connectivity when I migrate my database from one host/platform to another?

Perform the steps in the order listed:

  • Before the migration:
  1. Deregister the database tier from the Net Services Topology Data Model. Refer to the question “How do I deregister a database tier from the Net Services Topology Data Model?”
    If you haven’t enabled AutoConfig on the database tier, you can ignore this step.
  • After the migration:
  1. Reset the context variable s_apps_jdbc_connect_descriptor in the context file for the application tier to an empty string.
  2. Update the context variables s_dbhost and s_dbport in the context file for the application tier to reflect the new values in the middle tier context file.

32.  I migrated my database tier to a new host/platform, but the application tier still tries to connect to the old database. How can I fix this situation, so that the application tier connects to the new database?

Your old database tier is still registered in the Net Services Topology Data Model. Perform the following steps:

  • You have to clean up the data model by following the steps described in the question: “How do I purge the complete Net Services Topology Data Model?”.
  • Perform the step described in the question: “How do I seed the Net Service Topology Data Model?”

Troubleshooting

33.  What should I do if my AutoConfig script exits with non-zero status?

If AutoConfig exits with non-zero status, open the adconfig.log and check for the reported errors:

  • Errors in the instantiation phase: Check to see if the template files listed in the error summary exist in your file system. If they do not exist, the AutoConfig File Driver of the product is faulty. Report the problem to Oracle Support.
    If the template files exist, check for permission issues. If you cannot fix the issue, report the problem to Oracle Support.
  • Error encountered in the SETUP/PROFILE/APPLY phase: Check the adconfig.log file to see the reason for the failure. If you cannot fix the issue, report the problem to Oracle Support.
Note: Refer to the question “Where is the log file located that AutoConfig creates?” for the location of the log file.

34.  How do I configure AutoConfig to start the TCF servlet?

Perform the following steps:

  1. Apply the Thin Client Framework (TCF) Servlet Implementation patch.
  2. Apply TXK.A or higher.
  3. Verify that the s_tcfstatus variable is set to “disabled” in your <Context_name>.xml file.
  4. If set to “enabled”, use the Context Editor to update the TCF Process Status to “disabled” and save the changes.
  5. Stop all application tier services.
  6. Run AutoConfig to update the configuration files.
  7. Make additional updates based on your system configuration (see Note 164942.1).
  8. Restart all application tier services.

35.  How can I resolve TNS-12500 while trying to start GSM?

Change the profile option CONC_GSM_ENABLED to N until GSM is configured. If GSM is configured, check listener.ora located in
<8.0.6 ORACLE_HOME>/network/admin/<Context_name>

AutoConfig depends on the CONC_GSM_ENABLED profile option to create entries for FNDSM in the listener.ora file. If listener.ora contains entries for FNDSM and the corresponding executable is not found, the listener will not to start.

Apply the latest AutoConfig patch. The patch creates the FNDSM entry in listener.ora.

36.  My concurrent managers don’t start after running AutoConfig? How do I resolve this issue?

Look in the file APPLSYS_ux.env (Unix) or APPLSYS_nt.env (Windows) located in <AD_TOP>/admin/template. If the version of the file is 115.15 or lower, your environment file hard codes variables, which prevent the concurrent manager to start. Apply the latest AutoConfig patch to get the templates that use Application Context variables.

37.  How do I resolve a FileNotFoundException while running adupdts.sh?

If the script adupdts.sh fails with a “FileNotFoundException”, apply the latest AutoConfig patch.