This is a document that explains the basics of adpatch for REL11i.

This does not cover all

functions of adpatch, but should cover the primary functions that most people need to
understand. For complete information regarding adpatch, reference the Rel11i Maintaining
Oracle Applications manual.

Another adpatch document exists that covers adpatch functions for R10 and
R11. This document is available on Metalink, Doc ID 130608.1.

I. Types of Patches

Individual Patch, One-off, Standalone

These are terms used to describe an individual patch that is created to fix one particular bug.
Currently, most Application products deliver their patches primarily through Mini Packs.
Individual patches are possible, but rules for when one is created varies by product.

Mini Pack
Patch Set was the original term used in R10. In R11 the same type of patch is now being called
a Mini Pack. Both terms mean a large, cumulative patch, for a particular product, that fixes
most or all bugs that have been fixed for that release and product. These patches are.

Named using a letter.

11i.PA.D

Cumulative.
For example, 11i.AP.D, would include fixes in AP.A, AP.B, AP.C, plus bugs
fixed between when AP.C was released and when they began building AP.D.

Created periodically.
How often they are created varies by product.

Require just one patch.

However, if the install is a multi-node install, then the patch must be installed
on each machine.
If different platforms are used, the patch must be ported for each platform.

Family Pack

Family Pack is a group of Mini Packs for related products that are bundled together, and
possibly some additional individual fixes that have been created after the Mini Packs. Some
examples of product families are ERP, CRM, Procurement, or Order Management, but there are
many others.

The same bulleted information for Mini Packs applies for Family Packs. The only difference is
the naming structure. Family Packs will be named similar to:

11i.OM_PF.G or 11i.FINAP_PF.A

The _PF in the name indicates it is a Family Pack and not a Mini Pack.

FCUP or Family Consolidated Upgrade Patch

An FCUP (pronounced F-CUP) is a patch that needs to be applied before
starting an upgrade. This patch includes performance improvements or bug fixes
for processes that run during the upgrade. If an FCUP is required for an
upgrade, it will be mentioned in the Release Notes.

Consolidated Patch or Mega Patch

These are unofficial terms that are used to name, or describe, a large patch that is a bundle of
important bug fixes in one patch.

Maintenance Pack
Maintenance Pack is the term that Oracle began using for R11, while Release Update was used
for R10.
A Maintenance Pack is a collection of Mini Packs that are bundled together onto a set of CDs
that can be ordered and easily installed by the customer.

With the full installation of this type of patch, the 3rd digit of Applications Release
will change.
An example of a Maintenance Pack is 11.5.3 or 11.5.5

When applying a Maintenance Pack, a user can choose to apply certain products
Mini Packs individually, or they can apply all the products Mini Packs at once using
one set of drivers.
The Applications version will not be updated, for example to 11.5.5, if the
Mini Packs are applied individually.

As with Mini Packs, Maintenance Packs are cumulative.

So if 11.5.5 is applied, then prior Maintenance Packs do not need to be
applied.
(11.5.1, 11.5.2, 11.5.3, 11.5.4).

The primary purpose of Maintenance Packs is to fix bugs that have been identified.
However, on occasion new functionality may be introduced.

NLS Patches
If your install has multiple languages, additional patches may need to be installed for each
language. The
American patch needs to be applied first, then an NLS version of the same patch needs to be
applied for each language. When applying the NLS patch, be sure to set the NLS_LANG
variable to AMERICAN_AMERICA.<character set>, substituting the appropriate character set
for your language. For more information on other variables and steps, consult the NLS
Installation manual.

Not ALL patches will require an NLS version of a patch. For example, if the patch is only
creating a new
package, an NLS patch would not be required. However a patch that is replacing a form or
report, or all large patches, such as Mini Packs or Maintenance Packs will require an NLS patch.
Consult Oracle Support to confirm if an NLS patch is needed when applying a patch.

Adpatch has a function that was introduced in 11i that will alert the customer if an NLS patch
may be needed. During patch application, the user will receive a message that an NLS patch may
be required, and ask the user if they want to continue with the application of the patch.

Minor Release
Examples of a minor release are 10.7, 11.0, or 11.5. A minor release is not a patch.

A Minor Release is installed using autoUpgrade, not adpatch, to upgrade to the

release.

The primary purpose of a Minor release is to introduce new functionality.

Supported versions of Applications are based off of a Minor Release.

II. Basic Explanation of R11 Architecture

In order to understand how R11 patches are applied, the R11 architecture needs to be explained.
For a complete picture, reading the manual Oracle Applications Release 11 for UNIX Concepts
(Part# A90380) is recommended.

Documented below is a very simple explanation of R11i Architecture. Note, this is not a
complete description, and to get a full understanding the Concepts manual should be read.

Beginning with R11, Oracle allows the user to break up their install according to their needs. The
user can determine where to install 4 different servers. The Forms, Web, Concurrent Manager,
and Admin servers can be installed all on one machine or broken up onto numerous machines.
Database Tier
Concurrent Processing Server

Concurrent processes (Ex: reports, executables)

Administration Server

Files that maintain the database (Ex: patch/110/sql)

Application Tier
Forms Server

GUI Forms (.fmb and .fmx)

Web Server

html and java files

Desktop Client Tier

Contains appletviewer or JInitiator to log on to Applications from the client

Do not interpret the term Server, such as Forms Server, to mean a machine, such as Solaris or
NT. These servers can all be on the same machine (single node install), or divided into numerous
machines (multi-node install). For example, the user could have the Concurrent Processing
Server and the Administration Server on a Solaris, and the Forms Server and the Web Server on
an NT. This is the commonly used two-node type of install. Many other combinations can be
used, including multiple Forms Servers for Load Balancing or Fault Tolerance.

When a patch was applied in R11.0, the patch process asked 4 questions to determine which of
the 4 different servers existed on the machine the patch was being applied to. These questions are
listed below. In ( ) under the question is the server that these questions correspond to.

Do you currently have files used for installing or upgrading the database
installed in this $APPL_TOP [Yes] ?
(Administration Server)

Do you currently have Java and HTML files for Self-Service Applications
installed in this $APPL_TOP [Yes] ?
(Web Server)
Do you currently have Oracle Applications forms files installed
in this $APPL_TOP [Yes] ?
(Forms Server)

Do you currently have concurrent program files

installed in this $APPL_TOP [Yes] ?
(Concurrent Processing Server)

After these questions were answered, adpatch would know which files it needed to copy and the
jobs it would need to perform.

In R11i, the install process stores the answer to these 4 questions in the file
$APPL_TOP/admin/adconfig.txt. Then when adpatch is run, it reads this file
and automatically answers the 4 questions for the user. This makes adpatch
easier, and helps prevent user error.

Example:

The Applications instance has two machines.

Solaris Machine A, has the Concurrent Manager and Administration servers
NT Machine B, has the Forms and Web servers

The patch, ported for Solaris, would need to be applied to Machine A. The adconfig.txt file
would then be read and answer the 4 questions for the user. In this case the answers to the
questions should be, Yes for questions 1 and 4, and No for questions 2 and 3.

The same patch, ported for NT, would then be applied to Machine B, and the questions answered
in the reverse. Yes to 2 & 3. No to 1 & 4.

III. Anatomy of a Patch

All R11 and R11i patches use the zip function instead of tar, which was used in R10.

To unbundle the patch, simply use the unzip command:

unzip p2145632_11i_SOLARIS.zip

When a patch is unbundled it creates a directory that is the same number as the bug number
which is included in the patch name. For example, p2145632_11i_SOLARIS.zip will create the
directory 2145632. The 2145632 directory will contain the following:

readme.txt
fixes,

This is a text file that contains a brief explanation of what the patch
and instructions on how to apply the patch. It is VERY important
to thoroughly read this file, some examples of important
information it may contain are:

Prerequisite patch(s) that must be applied before

applying the current patch.

References to .html file(s) that are also included in the

patch, which contains additional installation steps or
instructions.

Manual steps that must be executed before or after

applying the patch.

An explanation of a new feature introduced by the

patch.

Restrictions on who or when the patch can be applied.

Instructions to run the patch in preinstall mode.

IMPORTANT: It is very important that the instructions in the

readme are followed closely. Not following the readme may
cause the patch to fail, not correct the problem it was intended
to fix, or potentially introduce additional problems.

cXXXXXX.drv

The c or copy driver, and the first driver file executed. A driver
provides adpatch with the instructions on the jobs it needs to
perform. This driver copies files from patch to directories, relinks
executables, and regenerates jar files.

dXXXXXX.drv

The d or Database driver, which is the second driver file

executed, if it exists. A patch will contain a database driver only if
the patch contains files that will update the database, such as files
in the patch/115/ sub-directories. Some examples, are scripts
that

dXXXXXX.cf

Create packages

Create new error messages

Add a new table or view to the database

Add a new column to a table

Add new seed data to a table

R11i patches created after December 2001 will include an

additional
d driver, but with the .cf extension instead of .drv. This is used by a
new adpatch feature, called the checkfile feature, which is
introduced in an AD Mini Pack, or with some individual AD
patches.

This feature is explained in depth by patches that introduce the

feature,

such as 1945611 or the latest AD Mini Pack. But the following is a

quick
explanation.

The checkfile feature can reduce the time to apply a d driver by not
running
processes that have already been run. Such as FNDLOAD,
WFLOAD, akload.class or any process in the d driver. It does this
by creating a table, which stores the versions for the files used by
these processes, then adpatch will check the version in the patch
against the version stored in this table. If the version in the patch is
not a higher version, then the process will be skipped. Adpatch is
run the exact same way, but the .cf driver file is used instead of
the .drv driver.

If a patch is applied using this driver without the new feature

installed, the adpatch session will fail at the start.

gXXXXXX.drv
if it

The g or Generate driver, which is the third driver file executed,

exists. A patch will contain a generate driver only if the patch

contains files,
such as forms, reports, graphics or messages, that need to be
generated.

jXXXXXX.zip

This zip file may be included in Java patches. This file is called a
Zipped Resource Unit or ZRU. If a patch contains a ZRU, it does
not need to be unzipped. This is a zip file that contains .class files
and other web related files. The .zip file will be called and applied
when adpatch is run with the c driver.

Product directories
etc.) that

Each patch will contain at least one product directory (ap, gl, inv,
will contain sub-directories and the files that are included in the

patch. The
product directories in the patch will mirror a $XX_TOP structure.
Meaning
the files will be in the same directories and sub-directories that are
found in the APPL_TOP product directories.

Example of an Unbundled Patch

Following is an example of the directory structure of an unbundled patch. After
p2145632_11i_SOLARIS.zip is unzipped, it creates the directory 2145632.

2145632
____________________|________________________
||||
ad c2145632.drv d2145632.drv readme.txt
|________________________________
|||
admin patch lib
|

||

115 115 adadmin.o

||
driver sql
| |____________
adcon.drv | |
adnuniq.sql aduvers.pls

IV. Installing a Patch

Following are the basic steps to installing a patch on R11i.

1. Have all Oracle Application users log out and shut down the concurrent managers.
2. Run the environment file found in $APPL_TOP to set the environment.
3. Make sure $ORACLE_HOME and $ORACLE_SID or $TWO_TASK are set correctly.
4. unzip the patch.
unzip p2145632_11i_SOLARIS.zip
5. Go to the patch directory created by unzip.
6. Read the readme and follow the instructions! If there are any steps to execute before
starting the patch, they must be executed first. Such as applying a prerequisite patch.
7. To begin applying the patch the first step will be to run the c driver, c2145632.drv. To start
the adpatch process, just type:
adpatch <return>
8. After the patch completes successfully, adpatch may need to be run again using a d
(database) and/or g (generate) driver that is included with the patch. Consult the readme for
specifics.

OPTION: Beginning with R11i AutoPatch has a non-interactive mode. Using

this mode, users can run all drivers for a given patch in a single non-interactive
AutoPatch session by using a defaults file. This is a very useful feature,
simplifying the patch process for the customer. Details on how to use this
feature can be found in the R11i Maintaining Oracle Applications document.

Following are examples of the questions that are asked when running adpatch.
In bold are additional comments that I have added to explain the questions and

their answers. Any values in [ ] are the default answer, and will be used if the
user just presses the enter or return key.

ADPATCH PROCESS

Your default directory is /u02/applmgr/PROD.

Is this the correct APPL_TOP [Yes] ?
This is just confirming your APPL_TOP. Some customers may have multiple
APPL_TOPs, for different instances, and this helps prevent someone from
accidentally applying a patch to the wrong APPL_TOP.

AutoPatch records your AutoPatch session in a text file you specify. Enter your AutoPatch log
file name or press [Return] to accept the default file name shown in brackets.
Filename [adpatch.log]
adpatch.log is the default. However, it is highly recommended that a log name that is
specific to the patch you are applying is used ( Examples, are 2145632.log,
c2145632.log 2145632_PROD.log). This way you can easily find and review the log
file for this specific patch. Otherwise, the log file will be appended to adpatch.log,
with all other patch log files.

Do you wish to activate this feature [Yes] ?

This feature is handy if you are applying a very large patch, such as a Mini Pack,
that you are not going to be able to sit by and monitor. If you use this feature,
adpatch will send an email to you if adpatch fails. The email will include the bottom
of the log file, which should have the error message. This feature is not really
necessary for smaller patches, or any patch you plan on monitoring the whole time.

If you answer Yes, adpatch will then ask the following question:

You chose to be notified by email when a failure occurs.

Please enter the email id(s) (separated by a space) that notifications should be
sent to [applmgr]:
You can enter one or multiple email addresses (separated by a space) for adpatch to
send a message to if it fails.

Please enter the batchsize [1000] :

The patch may contain scripts that update data in batches. This prompt allows
you to specify how many rows will be updated at a time. It is recommended that
you accept the default unless you know your system well.

Please enter the name of the Oracle Applications Environment that this
APPL_TOP belongs to.

The Applications Environment name must be unique across all Oracle

Applications Environments at your site, must be from 1 to 8 characters

long, and may only contain alphanumeric characters.

Sample Applications Environment names are: "prod", "test", and "demo".

Applications Environment Name [PROD] : PROD *

This question is automatically answered by the patch process.

NOTE: If you do not currently have certain types of files installed in this APPL_TOP, you may
not be able to perform certain tasks.
The following examples provided by adpatch are there to help explain the new R11
architecture discussed previously.

Example 1: If you don't have files used for installing or upgrading the database
installed in this area, you cannot install or upgrade the database from this
$APPL_TOP.
Example 2: If you don't have forms files installed in this area, you cannot generate them or run
them from this $APPL_TOP.
Example 3: If you don't have concurrent program files installed in this area, you cannot relink
concurrent programs or generate reports from this $APPL_TOP.
As discussed previously, the next 4 questions help determine which server(s) are on
the system you are applying the patch to. These questions will be automatically
answered by adpatch when it reads the file $APPL_TOP/admin/adconfig.txt.

Do you currently have files used for installing or upgrading the database
installed in this $APPL_TOP [Yes] ?
Do you currently have Java and HTML files for Self-Service Applications
installed in this APPL_TOP [Yes] ?

Do you currently have Oracle Applications forms files installed

in this $APPL_TOP [Yes] ?
Do you currently have concurrent program files installed
in this $APPL_TOP [Yes] ?

Please enter the name Oracle Applications will use to identify this APPL_TOP.

The APPL_TOP name you select must be unique within an Oracle Applications
Environment, must be from 1 to 8 characters long, and may only contain
alphanumeric and underscore characters.

AutoPatch has computed a default APPL_TOP name for you

based on the servers you have implemented in this APPL_TOP.

APPL_TOP Name [appslab31] : tafnw1

This question is also automatically answered by the patch process. This name is not
really
used by Applications, but is used by OAM.

You are about to apply a patch to the installation of Oracle Applications

in your ORACLE database 'PROD'
using ORACLE executables in '/u02/oracle/proddb/8.1.6'.

Is this the correct database [Yes] ?

This is confirming that you are applying the patch to the correct database. Some
customers may have multiple instances on a server, such as a TEST and
PRODUCTION instance. This helps prevent them from accidentally applying a
patch to the wrong database.

AutoPatch needs the password for your 'SYSTEM' ORACLE schema

in order to determine your installation configuration.
Enter the password for your 'SYSTEM' ORACLE schema:
Enter the SYSTEM password.

Connecting to SYSTEM......Connected successfully.

The ORACLE username specified below for Application Object Library
uniquely identifies your existing product group: APPLSYS
Enter the ORACLE password of Application Object Library [APPS] :
Enter the APPS password.

Identifier for the current session is 1336

Reading product information from file...

Reading language and territory information from file...

Reading language information from applUS.txt ...

Reading database to see what industry is currently installed.

Reading FND_LANGUAGES to see what is currently installed.

Currently, the following language is installed:

Code Language Status

---- --------------------------------------- --------US American English Base

Your base language will be AMERICAN.

Setting up module information.

Adpatch will then spool out a long list as it successfully connects to the different
products.
For example:

Connecting to CZ......Connected successfully.

Connecting to PJM......Connected successfully.

Enter the directory where your Oracle Applications patch has been unloaded
The default directory is [/u02/applmgr/PROD/patch/2145632] :
The default directory is the directory where adpatch is executed. If adpatch is
started from

the directory where the patch was unbundled, then just press <enter> to accept the
default.
If adpatch is started from another directory, such as /tmp, then enter the full path to
where the patch is unbundled.

readme.txt file spooled to screen.

If the patch has a readme.txt file, it will now be spooled out to the screen. This is to
encourage the user to read this file before applying the patch. This function may go
away in the future.

Please enter the name of your AutoPatch driver file:

Type in the name of driver file that needs to be used for this session of adpatch. For
example, d2145632.drv, or d2145632.cf, if the check file feature is installed.
Patch validation:
After entering the driver. Adpatch will then do a series of patch validation steps
before continuing. Information about the validation will be spooled to the screen. An
example of things that may be validated are:

Verify the patch release matches the release of the instance it is being
applied to.

Verify the platform of the patch against the platform it is being applied
to.

Determine if the files referenced in the driver file either exist in the patch
or on the current APPL_TOP.

Do you want to see the list of fixes in this patch [No] ?

Previously, this was automatically spooled out. Now it will ask if you want to see the
list of fixes included in the patch. Just press <enter> to continue without viewing the
list.
Enter the number of parallel workers [6] :

This determines the number of adworkers that will be created to apply the patch.
This prompt appears only if the driver contains the line compatible parallel yes or
compatible parallel always, or if the driver file contains at least one exec or sql
command. The default value is equal to the number of CPUs on the database server,
plus 2. It is recommended that the default be used, because this makes the patch run
faster. If you choose more than the default it may bog your database server down
and cause the patch to run slower.

That is the last question. Then adpatch begins to apply the patch.

V. Patch Failure or Successful Completion

How to tell if a patch completed successfully

If adpatch completes successfully, it will display a message like the following.

AutoPatch is complete.

AutoPatch may have written informational messages to the file

/u02/applmgr/PROD/admin/PROD/log/c2145632.lgi

You should check the file

/u02/applmgr/PROD/admin/PROD/log/c2145632.log

for errors.

What to do if a patch fails.

If the patch fails, adpatch may do one of the following. Included under each bullet are the basic
steps to restarting adpatch.

Errors and returns to the o/s prompt

1. Review log file(s) to determine the cause of the error.
2. Fix the cause of the error.
3. Restart adpatch.

4. Answer Yes when adpatch asks if you want to continue the previous
session.
5. Adpatch will skip already completed jobs, and pick up from where it left
off.

Informs the user that an error occurred and asks if you want to continue

With this type of error there are two options.

Option 1 - Discontinue Patch Session

1. Answer No, that you do not want to continue.
2. Review log file(s) to determine the cause of the error.
3. Fix the cause of the error.
4. Restart adpatch.
5. Answer Yes when adpatch asks if you want to continue the previous
session.
6. Adpatch will skip already completed jobs, and pick up from where it left
off.

Option 2 - Continue Patch Session

1. Make a note of the failure.
2. Choose to ignore the error and continue with adpatch.
3. After adpatch has completed go back and try to identify the problem and
complete the job manually.
4. An example of when this error may occur is 22 out of 23 reports generate
successfully, but one fails. Continue with the patch, then try to generate
the failed report manually after adpatch has completed.

Stops running after workers are spawned, and informs the user that workers
have failed. It asks for you to fix the problem and restart the workers. Adpatch does
not exit to the o/s, it just suspends working until the problem has been fixed and the
workers restarted.

Workers can be monitored and maintained using adctrl. If one worker fails the
others may
continue until itAt that point adpatch will inform you
that the errors in the workers must be corrected.
1. Review adworker log file(s) to determine the cause of the error.
2. Fix the cause of the error.
3. In another screen start adctrl
adctrl <return>
4. Answer the few questions required to start adctrl.
5. Pick option 2 Tell worker to restart a failed job
6. Type the worker number(s) you need to restart and press return. This will
restart the failed worker for adpatch.

For more information on adctrl, consult the Maintaining Oracle Applications manual.

VI. After Applying a Patch.

Oracle recommends that the following steps are completed after each installation of a patch.

1. Review log files for errors.

Details about the different log files that are created by adpatch are listed in #8 in the next
section.

2. Review customizations
If customized files have been registered in the file $APPL_TOP/admin/applcust.txt,
adpatch will list the files documented in applcust.txt that will be replaced during the
install of the patch. This file does not prevent the object or the patch from being applied,
it just lists the objects that will be replaced.

If you are concerned about customizations, there are a couple options to consider.
a. unbundle the patch and review the contents of the patch.
b. run the patch in test mode. See page 20 for details.

3. Consider removing backup or obsolete files

AutoPatch performs version checking before copying a file into the necessary directory.
If a file in a patch is determined to have a higher version than the existing copy, or it has
the same version but different file size, then the file is copied to the appropriate directory,
and the existing version is backed up. The backed up file is copied to a directory called
backup that is created in the unbundled patch directory.

If you are tight on space, you may want to periodically delete these backup files, as it can
begin to take up a lot of space. However, you should first confirm that the new files
works as you expected.

4. Maintain MultiLingual or Multiple Reporting Currencies Schemas(s)

If either the MRC or MultiLingual functionality is being used, the system needs to be
updated after applying a patch. This is done by running the Maintain MultiLingual or
Maintain Multiple Reporting Currencies options from adadmin

5. Pin SGA packages

The Installation Manual also suggests that if database objects are updated by the patch (a
D driver is run), the scripts ADXGNPIN.sql and ADXGNPNS.sql are run again to pin
new packages and sequences in your Oracle System Global Area. Details on this function
are also documented in the Installation Manual.

VII. Additional Patch Information

1. Is it OK to apply a patch when users are on the system?

As documented in the Installation Manual, Oracle advises that no users are logged on to
the system while a patch is being applied.

2. Retrieving information on patches or files that have been applied via adpatch
The first time you run adpatch, a file named applptch.txt is created. This file is created in
$APPL_TOP/admin/<ORACLE_SID>. This file is appended each time a patch is
applied. The file contains the following information:
a) Bugs not applied and why
b) Bugs applied. For each bug applied it lists
1. Actions executed
2. Actions not executed
3. From this detail you can see what files were applied to the system

There is also the file $APPL_TOP/admin/applsum.txt which is more of a summary of the

same information.

If you have applied a recent AD minipack, certain individual patches, or if you are on a
later version of 11i you will have a new adpatch function that stores this information into
new tables in the database. Past information from the applptch.txt file will also be loaded
into these tables, and then the applptch.txt file will no longer be used.

If your applptch.txt file has been successfully loaded into the database, then you should
see a file named something like...
applptch_succ_022602135156.txt

NOTE: If the initial install is a later version of R11i, it may have this function from the
start, and would never have an applptch.txt file.

With this new feature, reports can be run from the operating system to pull information
from the database. Following is a section that is included in patches that introduce this
feature. This explains how to run these reports.

Also, OAM, Oracle Applications Manager, has also been released. Once installed this
will allow the customer to easily pull the same information from a web application. OAM
also has many other beneficial features and uses that are very useful for a System
Administrator. Refer to note 166115.1 for more information on OAM and the installation
process.

(1) Patch History report usage:

adphrept <query_depth> < bug_number or ALL> <bug_product or

ALL> \
<end_date_from (mm/dd/rr or ALL)> <end_date_to (mm/dd/rr or ALL)> \
<patchname/ALL> <patchtype/ALL> <level/ALL> <language/ALL> \
<appltop/ALL> <limit to forms server? (Y/N)> \
<limit to web server? (Y/N)> \
<limit to node server? (Y/N)> \
<limit to admin server? (Y/N)> \
<only patches that change DB? (Y/N)>

Specify 1 or 2 or 3 for query_depth

1-> Details of patches only

2-> Details of patches and their Bug Fixes only
3-> Details of patches their Bug Fixes and Bug Actions

Example: To get the complete patch details for patches applied in

Dec 2000:

On UNIX:

$ cd $AD_TOP/patch/115/sql
$ sqlplus <APPS username>/<APPS password>
SQL> @adphrept.sql 3 ALL ALL 12/01/00 12/31/00 ALL ALL
ALL ALL ALL N N N
NN

On NT:

C:\> cd %AD_TOP%\patch\115\sql
C:\> sqlplus <APPS useord>
SQL> @adphrept.sql 3 ALL ALL 12/01/00 12/31/00 ALL ALL
ALL ALL ALL N N N
NN

(2) File version history report:

adfhrept <filename> <latest file version only? (Y/N)>

<start date(mm/dd/rr or ALL)> \
<end date (mm/dd/rr or ALL)> <patchtype/ALL> <language/ALL> \
<appltop/ALL> <limit to forms server? (Y/N)> \
<limit to web server?(Y/N)> \

<limit to node server? (Y/N)> \

<limit to admin server?(Y/N)> \
<only patches that change DB? (Y/N)>

Example: To get the complete file version history for admorgb.pls

considering only patches applied in Dec 2000:

On UNIX:

$ cd $AD_TOP/patch/115/sql
$ sqlplus <APPS username>/<APPS password>
SQL>

On NT:

C:\> cd %AD_TOP%\patch\115\sql
C:\> sqlplus <APPS username>/<APPS password>
SQL>

3. Stopping adpatch while the initial questions are being answered

If the final adpatch question has not been answered, then adpatch can be stopped at any
time by typing abort as the answer for any question. This will stop the adpatch session.
The next time adpatch is run, it will ask if you want to continue your last session.

4. Stopping adpatch after it has begun running

If a D driver is being applied, and it has spawned workers, it can be stopped by using the
program adctrl. Adctrl allows you to stop adpatch while it is running. It can also be used
to monitor adpatch and restart adworkers after they have failed. For more details consult
the Maintaining Oracle Applications Manual.

Otherwise, there is not a way to gracefully stop the adpatch process, other than killing the
process, so the best practice is to let it run to completion.

5. Always check for invalids, and recompile if necessary after applying a patch

If a d or database driver is used while applying a patch, the database should be

checked for invalids afterwards. Many times patches will create invalid objects,
and this could prevent the patch from fixing the issue it was correcting, or cause
other problems.

A new feature has been added to adpatch in R11i. This feature is not in the base release,
but is added by a patch. Any AD.F Mini Pack or greater will introduce this new feature.
With the new feature, at the beginning of adpatch it will create a file in the log directory,
for example 01361_preenv.lst. This file will list all invalid APPS objects in the database.
Then at the end of adpatch, it will create another file that lists the invalid APPS objects
after applying the patch.

Checking for Invalids:

Select owner, object_name, object_type from dba_objects where status = INVALID;

Compiling Invalid Objects:

Following are some options for compiling invalid objects.

Use adadmin to run Compile Apps Schema. Good to use if there is a large number
of invalid objects, because it compiles invalids for all APPS products.

$AD_TOP/sql/adcompsc.pls is a script that development will sometimes include as

one of the last jobs run by the d driver. This script allows you to compile invalid
objects in a given schema.
To run the script use the syntax
SQL> @adcompsc.pls <schema_username> <schema_password> <objects
starting with>
Examples:
SQL> @adcompsc.pls apps apps PA (This will compile all the objects in Apps
starting with PA%)
SQL> @adcompsc.pls ap ap % (This will compile all objects in the AP schema)

Recompile and recompile.sql. These are custom scripts that were created by a support
analyst at Oracle. The script selects all invalid objects and dynamically creates alter
scripts to compile each of these invalid objects, then runs the scripts. For examples of
these scripts look in the reference section, on page 30.

Use alter command in sql:

ex: alter package ARP_STANARD compile body;
alter package ARP_STANARD compile;
alter view TABLE_V compile;
alter java class /584c2e1f_FunctionManager1 compile;

If you find an object with the object_type UNDEFINED, then you might want to try...
alter snapshot object_name compile;

If you have invalid SYSTEM or SYS objects you can use

$ORACLE_HOME/rdbms/admin/utlrp.sql to compile just these invalid objects.

6. Where are the log files for the patch process stored?
The log files that are generated during the patch process are stored in
$APPL_TOP/admin/<ORACLE_SID>/log

7. Other adpatch application options

There are a few different modes in which adpatch can be run.

Test Mode
Test mode will display all the files adpatch will replace and the actions it will take, but
does not actually apply the patch. The syntax for using this mode is:
$ adpatch apply=no
This is useful if the user wants to know exactly what a patch will do before applying the
patch. For example, if the user is concerned about customizations being replaced.

Pre-AutoInstall Mode

There are times when Oracle may require the install of a patch before running AutoInstall
to install or upgrade Oracle Applications. The patch usually updates AutoInstall itself or
one of the utilities it calls during the installation. The syntax for this mode is:
$ adpatch preinstall=y

Non Interactive Mode

As mentioned earlier in the document, this is a mode where you can apply all of the
drivers with one adpatch command, rather than running adpatch several times. To do this
you must create an AutoPatch defaults file, which contains information for running
adpatch against the different drivers. Consult the Maintaining Oracle Applications
document for the details on running adpatch in this mode. It is a fairly simple process, but
the directions are more than I would like to add to this document.

Options parameter
The options parameter can be used to enable or disable certain functions during
application of the patch. For example, you may want to prevent forms and libraries from
being generated during the application of a patch. The syntax for this would be:
$ adpatch options=nogenrep,nogenrpll

AD Merge option
AD Merge Patch is a process that merges multiple compatible patches into one integrated
patch.
The command that is used is admrgpch. Once again, for details consult the Maintaining
Oracle Applications document. This is a very useful feature if a large number of patches
need to be applied at one time.

Full details on all of the available options are in Maintaining Oracle Applications
manual.

8. IMPORTANT: Other log files generated by adpatch

If a patch process errors, the first step is to find the error that caused the failure. This
error may not be in the main log file (the log name that is entered by the user at the start
of adpatch). When a patch is applied, it may generate other log files besides the log name
that is entered at the start of adpatch.

Following are some log files that may also be updated by the patch.

adlibin.log

(libin commands)

adlibout.log

(libout commands)

admvcode.log

(copying files to destination)

adrelink.log

(relinking executables)

adwork01.log

(adwork02.log, adwork03.log, etc. Depending on # workers used.

Generated by the D and G drivers)

.req files
(Some processes may generate .req files. There are numerous
different
commands that generate a .req file. Below is one
example. This line was
found in a adwork01.log file.

/u02/applsean/FRESH/fnd/6.1.1/bin/FNDMDGEN APPS/APPS 0 Y US PO
SCRIPT_TO_DB po
patchsc/107/import/po10sc.msg
Log filename : /u02/applsean/FRESH/install/log/l1189.req (Review this file for the
error)
Report filename : /u02/applsean/FRESH/install/out/ANONYMOU.1189

Providing log files to Support

If a problem is encountered while applying a patch, be prepared to provide the
appropriate log files before calling Oracle Support. This will help expedite the resolution
of the issue. Since most of the log files are appended by each patch applied, these log
files may be very large. If so, there are ways to extract the section that shows the error.

One option is to pull up the file with vi, or an editor, and cut the appropriate section out
into a smaller document. If this method is used, be sure to include about a page before
and after the error to assure that all important information is included. Sometimes
important information, or other errors are included before or after the most obvious error.

Another nice option is to backup/rename the log file that is needed and reapply the patch
to get the error. For example, a patch is failing during relinking.
a. First backup the current log file
mv adrelink.log adrelink.bk
b. Rerun the patch so that it will error again.
c. A new adrelink.log file will be created that only contains info from the current patch.
d. Rename this new log file, then restore the backup.
e. This file will contain only the errors from this patch, and will not be as large as the
original log file.

9. What is the j<patchnumber>.zip file that exists in some 11i patches?

You may find this type of zip file when applying Java patches in 11i. These zip files are
known as
a Zipped Resource Unit. You do NOT have to unzip this file. It will be applied by the c
driver when adpatch is run. Somewhere in the c driver will be a jcopy command. The
jcopy command removes the contents of the .zip file and merges them into your apps.zip
file, which is located in the $AU_TOP/java directory. This jcopy command replaces the
old class files with new ones found in the .zip file from the patch. Your apps.zip file in
your $JAVA_TOP will also be updated by the jcopy command.

10. Job Timing Report

Adpatch also creates a Job Timing Report which provides time statistics
on the application of the
patch. This report includes useful information, such as...

Which jobs took the longest, and how long each one took.

Timing information for each patch phase

Percent usage by product

Percent usage by phase and product

This report is placed into the $APPL_TOP/admin/<SID>/out directory. You should see a
line like the following at the end of the adpatch log file.

A job timing report has been generated for the current session. You
should check the file
/u02/applmgr/prodappl/admin/PROD/out/adt01361.lst

11. Auto Restart when workers during D driver fail

Most d drivers will spawn adworkers to run jobs in parallel. As discussed previously,
when the
workers fail, you can restart them via adctrl. However, adpatch also has a feature that will
restart
the failed jobs for you.

When all the jobs are in a failed or waiting status, adpatch will automatically restart all
the
failed jobs one time. If the jobs then fail again, adpatch will stay in the failed status until
the
problem is resolved and the workers are restarted using adctrl.

Sometimes, a job may fail due to a database lock on a table, or because it is dependent on
another job that has not completed yet. This auto restart function should correct these
type of errors, and allow the patch to continue without user intervention.

VIII. Explanation of Driver Files

Driver files, or .drv files, are files that adpatch uses to determine what jobs to perform. The
following section provides a basic explanation on how to read a driver file and understand the
jobs it will perform.

A. Copy driver, cXXXXXX.drv

The copy driver is the first driver, which must be run using adpatch. This driver will do the
following functions.
a) copy the files from the patch to the appropriate directory
b) relink executables
c) regenerate jar files

The general form of a driver command line is:

<command> <product>

<subdirectory>

<file>

<other arguments>

Some of the common <command>s that are used are:

Copy

copy file into target sub-directory with version checking

forcecopy

copy file into target sub-directory without version checking

libout

extract object module from library

libin

put object module into library

genform

generate form

genrep

generate report

genrpll

generate Oracle Reports PL/SQL file and copy to $AU_TOP/plsql

copy

link

relink executable

exec

run executable program

sql

Run SQL script.

ap

forms/US

APXIISIM.fmb

110.8

Driver will check the versions of APXIISIM.fmb on your system. If it is less than 110.8, then it
will
copy this file to the $AU_TOP/forms/US directory.

IMPORTANT NOTE: This file is copied to $AU_TOP, not $AP_TOP, even though it is an AP
form. ALL forms, or .fmb files, copied to $AU_TOP/forms. These are the text files. Then when
the g driver is run, these binary files are generate, and the form executable or .fmx is generated.
This .fmx is then stored in $AP_TOP/forms, or the appropriate $XX_TOP/forms directory.

copy

ap

patch/110/sql apaiithb.pls

110.2

Driver will check the versions of apaiithb.pls on your system. If it is less than 110.2, then it will
copy this file to the $AP_TOP/patch/110/sql directory.
copy

fnd

resource

JE.pll

110.8

Driver will check the versions of JE.pll on your system. If it is less than 110.8, then it will copy
this file to the $AU_TOP/resource directory.

IMPORTANT NOTE: Again, note that the file is copied to $AU_TOP, just like the .frm file.
However, the difference with form library files, or .pll files, is that when they are generated the
executable file, .plx, remains in the same $AU_TOP/resource directory.

libout

ar

lib

arstax.o

copy

ar

lib

arstax.o

70.143

libin

ar

lib

arstax.o

Driver will first extract the .o file from your libar.a file in $AR_TOP/lib (libout). It then performs
a
version check. If the current version is less than 70.143 it copies the .o file from the patch to
$AR_TOP/lib (copy). It then inserts the .o file back into libar.a (libin). Later, when the patch
relinks
the executables, the libar.a file is used, and the new file will be linked into the executable.

link

fnd

bin

aiad

Relink the executable $FND_TOP/bin/aiad.

link

oe

bin

OEBSHC

Relink the executable $OE_TOP/bin/OEBSHC

Following is a simple explanation of relink:

Executables are numerous C modules bundled together to create the executable. Linking, or
adrelink, is the process that bundles all the necessary C modules together to create the
executable. In order for the new C code, or object files (arstax.o for example) to take affect, they
not only have to be inserted in the products C library (libar.a or libap.a), but the executables that
use this C code must be relinked. This command is the same as if you ran the following
commands from the o/s.
adrelink force=y oe oebshc

jcopy
You might find a jcopy command in a R11i patch if it is updating Java files. This command is
explained in the Additional Patch Information section on page 21.

B. Database driver, dXXXXXX.drv

This is the driver that runs .sql, .pls, .odf and other files that update the database. As mentioned
previously, some common ways the database is updated by the this driver are:

Create packages

Create new error messages

Add a new table or view to the database

Add a new column to a table

Add new seed data to a table

The database driver uses the same command structure:

<command> <product>

<subdirectory>

<file>

<other arguments

>

However, as you will see, it uses the <other arguments> section much more. There are numerous
different arguments that can be used, but following are some more common examples:
sql

Run the script directly from the worker

sqlplus Spawn a new sqlplus session and run the script

package Same as sqlplus but performs package version checking

Another argument you may see at the end of the command string is a phase command. Before
performing any actions, adpatch divides all actions contained in the patch driver file into phases
based on information specified in the patch driver. Adpatch performs all actions grouped in one
phase in parallel before proceeding to the next.

Many d drivers in patches contain phase definitions that determine what order the files in the
driver will run. If the driver does not contain any phase definitions, then the files are executed in
the order they appear in the driver.

Following are a few examples of types of phases.

Phase name

Action taken

seq

Create sequences

tab

Create tables and indexes

pls

Create package specifications (specs)

vw

Create Views

plb

Create package bodies

Following are some examples of common commands found in a dXXXXXX.drv driver, and a
brief explanation.

sql ar patch/115/sql b512706a.sql !AR_PERIOD_TYPES &un_ar &pw_ar sql

&phase=tab
Run the sql script $AR_TOP/patch/115/sql/b512706a.sql using the ar username and password.
The
!AR_PERIOD_TYPES is anoy the .sql script. As discussed previously the
&phase argument specifies what type of action this script is doing, and when the script will be
executed
by the driver.

sql ar patch/115/sql ARTEHPCS.pls none none none package &phase=pls

Run the script $AR_TOP/patch/115/sql/ARTEHPCS.pls which creates a package (phase=pls).

sql ar patch/115/sql artcall5.sql none none none sqlplus &phase=tbm+5 &un_ar &pw_ar
Run the script $AR_TOP/patch/115/sql/artcall5.sql. The +5 is a way of determining the order a
script
will run within a phase. For example, within a phase, commands would be run in the following
order:
&phase=tbm
&phase=tbm+5
&phase=tbm+99

exec ad patch/115/odf adutil.odf odf &phase=seq mode=sequences

This command will run the adutil.odf file. .odf files are files that create or
update the structure of tables, sequences and views. This command is being run
in mode=sequences, so it will be creating sequences with this command.

C. Generate Driver, gXXXXXX.drv

Following are some examples of commands in a g driver. Once again, remember that

The .fmb files are stored in $AU_TOP, and when generated the executable (.fmx) is stored
under the product.

The .pll is stored under $AU_TOP, and when generated the executable (.plx) is also stored
under $AU_TOP.

genform

ap

forms/US

APXIISIM.fmb

Generate the form $AU_TOP/forms/US/APXIISIM.fmb and store the executable in

$AP_TOP/forms/US/APXIISIM.fmx

genrep

ap

reports

APXIIADV.rdf

Generate the report $AP_TOP/reports/APXIIADV.rdf, and store the resulting file APXIIADV.rdf
in the same directory.

genfpll

fnd

resource

JE.pll

Generate the PL/SQL library $AU_TOP/resource/JE.pll, and store the executable JE.plx in
$AU_TOP/resource.

D. Other Commands
Following are some other commands that may be found in a driver file. Once again, this does not
cover all commands that may be found in a driver file, but these are some common ones that may
be of interest.

compatible release 11.5.0

This command checks the release the customer is on to verify they are applying the
correct
patch. Patches are specific to release versions. That is why when you will see separate
ARU
checkins by release, and have to specify a release when requesting an ARU.

compatible parallel yes

compatible parallel no

This command determines if parallel mode will be used when applying the
patch. Parallel mode
works essentially the same was AutoInstall, where it starts up workers and the workers
execute
certain commands.

compatible platform
Prevents customers from applying patches for an incorrect platform.

compatible language
Prevents customers from applying patches for an incorrect language.
compatible translation_required

When applying a US patch, informs users when language patches may be required in addition to
the current patch.

X. Recompile and Recompile.sql scripts.

Following are examples of the recompile scripts and instructions on implementing

recompile
sqlplus system/manager
rm -Rf /tmp/recompile-sql.sql

recompile.sql
column owner format a1 noprint
column object_name format a1 noprint
column order_col format a1 noprint
column cmd format a132

set heading off

set pagesize 0
set linesize 180
set echo off
set feedback off

spool recompile-sql.sql

select 'set echo on' from dual;

select 'spool recompile.lis' from dual;

select distinct 'alter session set current_schema=' || owner || ';' cmd,

owner,
1 order_col,
NULL object_name
from dba_objects
where status = 'INVALID'
and object_type in ('PACKAGE','PACKAGE BODY','VIEW','PROCEDURE',
'FUNCTION','TRIGGER','TYPE','TYPE BODY','INDEXTYPE',
'JAVA CLASS')
union
select 'ALTER ' ||
decode(object_type, 'PACKAGE BODY', 'PACKAGE', 'TYPE BODY', 'TYPE',
object_type) || ' ' || owner || '.' || '"' || object_name || '"' || ' COMPILE' ||
decode(object_type, 'PACKAGE BODY', ' BODY', 'TYPE BODY', ' BODY':p>
';' cmd,
owner,
2 order_col,
object_name
from dba_objects outer
where status = 'INVALID'
and object_type in ('PACKAGE','PACKAGE BODY','VIEW','PROCEDURE',
'FUNCTION','TRIGGER','TYPE','TYPE BODY','INDEXTYPE',

'JAVA CLASS')
and (object_type <> 'PACKAGE BODY'
or not exists
(select null
from dba_objects
where owner = outer.owner
and object_name = outer.object_name
and object_type = 'PACKAGE'
and status = 'INVALID'))
and (object_type <> 'TYPE BODY'
or not exists
(select null
from dba_objects
where owner = outer.owner
and object_name = outer.object_name
and object_type = 'TYPE'
and status = 'INVALID'))
order by 2,3,4
/

select 'exit;' from dual;

spool off;

set heading on
set feedback on
set pagesize 9999
set linesize 80

@recompile-sql

Instructions
1. create recompile and recompile.sql scripts from the above examples.
2. Modify recompile file, putting the correct address on your system where you are storing
recompile.sql
3. chmod 777 recompile (or make recompile an executable file)
4. run recompile
$ recompile [return]