Patch Application Utilities

Various utilities are available for applying patches to your Oracle E-Business Suite system. Their features and usage are described here.

This chapter covers the following topics:

Oracle Patch Application Assistant
AutoPatch
AD Merge Patch

Oracle Patch Application Assistant

For patches that have manual steps, the patch readme file instructs you to use Oracle Patch Application Assistant (PAA) by running the admsi.pl script. For merged patches, PAA automatically merges the contents of the individual patch readme files.

The Oracle Patch Application Assistant Interface

The Patch Application Assistant is started from the command line, and collects your input in a graphical user interface.

Running Oracle Patch Application Assistant

The following is a summary of the steps you use to run Patch Application Assistant. For a complete description of all the steps, see Creating Customized Instructions for Patching Using PAA.

Step 1: Set the environment

You must set the environment to apply the configuration parameters that define your system. This task is common to many AD utilities.

Step 2: Unzip the patch

Create a patch top directory, if it does not already exist. Download the patch into the patch top directory and unzip it.

Step 3: Review the information in the readme file

In the directory where you unzipped the patch, you will find a README.txt file and a README.html file. Review either of these files for information about the patch and for instructions on using Oracle Patch Application Assistant to generate customized instructions for your system.

Step 4: Run Oracle Patch Application Assistant

Run PAA (admsi.pl) to generate customized instructions for your system. Follow the steps in the customized instructions to complete the patching process.

AutoPatch

You use AutoPatch to apply patches to the Oracle E-Business Suite file system or database. The utility gathers the required information about your system via a series of prompts. When you have responded to the prompts, AutoPatch performs the tasks required to apply the patch:

Reads patch metadata to determine patch dependencies and requirements
Uploads patch information from a prior patch session to the database (if applicable)
Reads and validate the patch driver file and reads the product driver files
Compares version numbers of object modules from the product libraries and version numbers of the existing files against the patch files
Backs up all existing files that will be changed by the patch
Copies files
Archive files in libraries
Relinks executables
Generates forms, reports, messages, graphics, and Java archive (JAR) files.
Compiles JSP files and invalid database objects
Updates database objects
Runs AutoConfig to update configuration files if any template files are introduced or updated by the patch
Saves patch information to the database

AutoPatch takes no action if a patch contains no new updates to files or database objects in your system.

If AutoPatch detects a previously failed AutoPatch session, it will attempt to recover that session.

Preparing your System for Patching

Before you begin a patching session, there are some important tasks you need to complete.

Enable Maintenance Mode

Before you initiate an AutoPatch session, you must shut down the Workflow Business Events System and set up function security so that no Oracle E-Business Suite functions are available to users. This ensures optimal performance and reduces downtime when applying a patch. Maintenance mode provides a clear separation between normal runtime operation of Oracle E-Business Suite and system downtime for maintenance.

During a Maintenance mode downtime, user login is restricted. Users are redirected to a system downtime URL, which informs them that the maintenance session is in progress. The Oracle Applications Manager (OAM) Maintenance Mode page allows you to schedule system downtime and send alert messages to notify users of the downtime schedule.

To enable or disable Maintenance mode, use the Change Maintenance Mode menu in AD Administration. See: Changing Maintenance Mode, Oracle E-Business Suite Maintenance Utilities.

Caution: You can run AutoPatch by using options=hotpatch on the command line when Maintenance mode is disabled. However, applying a 'hot patch' may result in significant degradation of system performance. For more information, see AutoPatch Options.

Shut Down Services

If you are applying a patch that updates or relinks files, shut down the corresponding concurrent managers, Web services, or Forms services. See: Applying a Patch Interactively.

Log Files

In addition to the main log file (adpatch.log), AutoPatch also creates several other log files for specific purposes, for example, to record all the actions associated with parallel workers. The log files are written to $APPL_TOP/admin/<SID>/log (UNIX), where <SID> is the value of your ORACLE_SID or TWO_TASK variable, or in %APPL_TOP%\admin\<SID>\log (Windows), where <SID> is the value of ORACLE_SID or LOCAL. Review these files when the AutoPatch session is complete.

The log directory contains adpatch.log and adpatch.lgi, and may contain one or more additional files as described in the following table.

Log Files
Log File	Used For
adpatch.log	Main AutoPatch log file (default name)
adpatch.lgi	AutoPatch informational messages (default name)
adrelink.log	Relinking
adlibin.log	Moving C object files into the C library of a product
adlibout.log	Moving C object files out of the C library of a product
adworkxxx.log	Database operations run in parallel
<language>_<filename>_ldt.log	Seed data loader files

Note: You can also review log files using the View Log Files feature of OAM Timing Reports. See: View Log Files.

If AutoPatch does not perform an action, it does not generate the log file associated with that type of action.

Prompts

In addition to the standard prompts common to most AD utilities, AutoPatch also asks for information specific to the patching process. You must respond to all the prompts for each driver you run.

Important: Do not run multiple sessions of AutoPatch on the same Oracle E-Business Suite system at the same time.

Main Log File Name

The main AutoPatch log file is named adpatch.log by default. We recommend you change the name to indicate the associated driver file, using a .log extension. For example, for the u1234567.drv driver, the log file should be u1234567.log.

SYSTEM and AOL User Passwords

AutoPatch prompts for the SYSTEM and AOL user passwords.

Note: You can change this behavior by using options=validate on the command line. See Command Line Arguments.

Patch Directory

AutoPatch asks you to specify the directory where the patch files have been unzipped. The default is the directory from which you started AutoPatch. If necessary, specify the full path name to the directory where you unzipped the patch files. The operating system user running AutoPatch must have write permissions to that directory.

Patch Driver File

AutoPatch prompts for the name of the patch driver file. By default, it does not check the integrity of the patch - that is, whether the version of each file referenced in a driver file copy action matches the version in the patch - because Oracle E-Business Suite patches are always tested before release to ensure they contain the correct files.

The unified driver, named u<patchnum>.drv, contains the commands necessary to change files and database objects, and to generate new objects. It contains copy, database, and generate portions and performs the copy, database, and generate actions in the stated order. You typically run the unified driver on all APPL_TOPs and AutoPatch runs only the actions that are required for the current APPL_TOP. However, there may be cases where you run only the applicable portion of the driver.

Copy Portion of a Unified Driver

When the copy portion of a unified driver runs, AutoPatch performs the following actions:

Extracts the appropriate files from the C library of each product.
Compares the extracted object modules with their corresponding files in the patch directory. It also makes this type of comparison with files such as forms, reports, and SQL scripts.
Backs up any product file with a more recent version in the patch directory to a subdirectory in the patch directory. For example, if <patch_dir> is the patch directory, <system_name> is the Applications System name, <appl_top_name> is the APPL_TOP name, and <prod> is the name of the product being patched, it backs up:
```
<PROD>_TOP/<subdir(s)>/<old_file_name>
```
to
```
<patch_dir>/backup/<system_name>/<appl_top_name>/<prod>/<subdir(s)>/<old_file_name>
```
Note: The Applications system name and the APPL_TOP name are determined during the Rapid Install process.
Replaces the outdated files of each product with newer files from the patch directory.
Loads the new object modules into the C libraries.
Relinks the Oracle E-Business Suite products with the operating system, Oracle server, and other Oracle products libraries.
Applies changed Java class files and regenerates JAR files as needed.
Copies any specified HTML or media files to their respective destinations.
Compiles out-of-date Java Server Page (JSP) files (if any JSP files are included in the patch).

Database Portion of a Unified Driver

When the database portion of a driver runs, AutoPatch performs these actions:

Gets a list of current invalid objects in the APPS schema.
Determines whether the action was performed in a previous patch.
Runs SQL scripts and EXEC commands, which change Oracle E-Business Suite database objects. By default, AutoPatch runs scripts and commands in parallel.
Compiles invalid objects in the database.
Assembles a list of current invalid objects in the APPS schema.

Note: As of Release 12, a separate MRC schema is not required, so Invoker's Rights processing (included in previous releases) has been removed.

Generate Portion of a Unified Driver

Apply the generate portion of a unified driver on all APPL_TOP directories containing one or more files being generated by the patch. If in doubt, apply it to all APPL_TOP directories on all nodes. When the generate portion of a driver runs, AutoPatch performs these actions:

Generates Oracle Forms PL/SQL library files
Generates Oracle Forms menu files
Generates Oracle Forms executable files
Generates Oracle Reports PL/SQL library files
Generates Oracle Reports files
Generates message files
Generates Oracle Workflow resource files

Note: You can change this behavior by using options=integrity on the command line. See Command Line Arguments.

Number of Parallel Workers

By default, AutoPatch runs database updates and file generation commands in parallel and prompts you for the number of workers. Tasks are assigned to workers, the workers run the tasks to completion, and AutoPatch assigns new tasks.

The default value for the number of workers is two times the number of CPUs on the node from which you run AutoPatch. Oracle recommends specifying the number of workers as between two and four times the number of CPUs.

After you specify the number of workers, AutoPatch displays messages similar to the following as it begins to update the Oracle E-Business Suite products:

Performing version checking for driver files...
Copying driver files into installation area...
Determining valid on-site files...
Screening out files not valid for this installation...
Extracting object modules from product libraries...
Performing version checking...
Determining what executables to link...
Determining what Oracle Forms files to generate...
Determining what Oracle Reports libraries to generate...
Determining what Oracle Reports files to generate...

AutoPatch runs all database actions based on phase order, a grouping of actions in the database portion of the patch that minimizes dependencies. This order is not necessarily the order in which the commands are listed in the database portion of the patch driver.

Note: For more information, see Monitoring and Controlling Parallel Processing, Oracle E-Business Suite Maintenance Utilities.

Customized Files

AutoPatch reviews the AD_FILES table to determine if any customized files (Register Flagged Files) will be replaced by the patch. If so, it displays a message listing the customized files it will replace.

Note: For more information, see Customization Standards, Oracle E-Business Suite Developer's Guide, and Register Flagged Files.

NLS

If the patch you are applying has an NLS-related version, and if you are an NLS customer, AutoPatch prompts you about the NLS-related version of the patch before allowing you to continue.

Preparing for Non-Interactive Patching

Non-interactive patching is a way to save time by avoiding some of the prompts and automating the patching process. To use non-interactive patching, create a defaults file by running AutoPatch interactively using a specific command line option. Then tell AutoPatch to run non-interactively by providing the name of the defaults file plus other associated command line options. After the AutoPatch actions are complete, you perform any post-AutoPatch steps listed in the patch readme file. See Performing Non-Interactive Patching.

Messages

AutoPatch generates several types of messages. Each message is recorded in a log file. See Log Files for a list and descriptions.

Informational Messages

Informational messages are written to the informational message file (adpatch.lgi). This log file uses the same base file name as the main AutoPatch log file, but substitutes a .lgi extension for the .log extension. For example, if the AutoPatch log file is named u1234567.log, the AutoPatch informational log file is named u1234567.lgi.

For example, AutoPatch writes information pertaining to the files not updated because they are up-to-date in the informational log file.

File will not be copied to destination.

Version check:
/slot03/appmgr/prodappl/ad/12.0.2/xml/oam/patch/history/SearchFiles.uix
version is equal to or lower than
/slot03/appmgr/prodcomn/html/oam/patch/history/SearchFiles.uix.
File will not be copied to destination.

Version check:
/slot03/appmgr/prodappl/ad/12.0.2/xml/oam/patch/history/SearchFilesCriteriaAdvanced.uix
version is equal to or lower than

/slot03/appmgr/prodcomn/html/oam/patch/history/SearchFilesCriteriaAdvanced.uix

Error Messages

When AutoPatch is using parallel processing and an error occurs, the job fails. Review the main log file (adpatch.log) and the adworkxxx.log file to determine the source of the error, resolve the issues and continue. Restart AutoPatch using the adctrl command.

Note: See Monitoring and Controlling Parallel Processing, Oracle E-Business Suite Maintenance Utilities, for details on using the adctrl command.

If you cannot resolve the issue, you must:

Verify that all steps in the readme file were completed.
Check My Oracle Support for additional information regarding the patch you are applying.

If the message indicates that a worker has failed its job, you can fix the problem and restart the worker while the manager is running. Some failed jobs are deferred (not immediately reassigned) by the manager. These jobs do not cause the manager or other workers to stop.

See: Managing Worker Processes, Oracle E-Business Suite Maintenance Procedures.

Successful Completion Message

AutoPatch displays messages such as the following when processing is complete. If you do not see a completion message, you should investigate and identify the reason.

A job timing report has been generated for the current session.
You should check the file
    /slot03/appmgr/prodappl/admin/PROD/out/adt323790.lst
for details.


Purging timing information for prior sessions.

sqlplus -s APPS/***** @/slot03/appmgr/prodappl/ad/12.0.0/sql/adtpurge.sql 10 1000

Done purging timing information for prior sessions.

AutoPatch is complete.

AutoPatch may have written informational messages to the file
/slot03/appmgr/prodappl/admin/PROD/log/adpatch.lgi

Errors and warnings are listed in the log file
/slot03/appmgr/prodappl/admin/PROD/log/adpatch.log

and in other log files in the same directory.

Backup Directory

When AutoPatch runs, a backup directory is created in the directory where you unzip the patch. The old version of each file updated by the patch is copied into the backup directory. When applying large patches (such as release update packs, product family RUPs, and pre-upgrade patches), ensure there is enough disk space on the system where you unzip the patch, or the patching process may fail. We recommend having at least twice the amount of disk space as the unzipped patch file uses.

Tip: Periodically, you can delete the files in the backup directory to free the space.

AutoPatch Modes

AutoPatch can apply patches in two specialized modes: pre-install and test. The patch readme file instructs you when to use each of these modes.

Pre-Install Mode

Pre-install mode is generally used during the upgrade process to update AD utilities, apply pre-upgrade patches, or work around other patching issues. AutoPatch asks all startup questions except those relating to the database.

Note: Run AutoPatch in pre-install mode only if the patch readme instructs you to do so.

To run AutoPatch in pre-install mode, include preinstall=y on the AutoPatch command line. It performs the following actions:

Compares version numbers
Copies files
Relinks FND and AD executables
Saves patch information to the file system

Because AutoPatch does not read driver files in pre-install mode, it copies all product files in the patch to the APPL_TOP directory. Additionally, even if a file in the patch should be both in the APPL_TOP and in another directory (such as in $OA_HTML), AutoPatch copies the file only to the APPL_TOP.

Each patch run in pre-install mode will have its driver staged to a predetermined directory under the APPL_TOP. This allows AD Merge Patch to be run once for all pre-install updates, and merging with the upgrade driver only. See AD Merge Patch Enhancements for further details.

In preinstall mode, AutoPatch validates codelevels against the files Preinstall_Codelevel_AD.txt and Preinstall_Codelevel_MP.txt. These files are located in the $APPL_TOP/admin directory, and contain codelevel information about AD and other products registered in the database tables.

Since no database connection is available in pre-install mode, AutoPatch tries to validate whether the current patch should be applied based on the codelevel information in these two files, as follows:

If Preinstall_Codelevel_AD.txt is missing from the APPL_TOP, AutoPatch will apply the patch in pre-install mode without validating the patch for codelevel compatibility.
If Preinstall_Codelevel_MP.txt is missing from the APPL_TOP, AutoPatch will proceed with patch application without validating the patch for codelevel compatibility of the entities.
If both files are missing, AutoPatch will not validate codelevels in pre-install mode.

Note the following restrictions when applying a patch in pre-install mode:

NLS patches cannot be applied on the instance.
Baseline or codelevel-introducing patches cannot be applied on the instance.
AutoPatch will not check to see if the patch is already applied on the system.

Test Mode

In test mode, AutoPatch does not apply the patch. Instead, it lists each file it would have copied, relinked, executed, or generated and shows exactly what actions it would have performed had it applied the patch. It also runs AutoConfig in test mode to determine any impending changes to the configuration files. This allows you to see the effects of the patch on your production system before you apply it.

To run AutoPatch in test mode, include apply=no on the AutoPatch command line. This runs as if AutoPatch is applying the patch, except it does not. It performs the following actions:

Copies any files from the patch directory to the Oracle E-Business Suite file system
Archives any object modules into the product libraries
Relinks any executables
Generates any forms, reports, PL/SQL libraries, or menu files
Runs any SQL or EXEC commands (commands that change the database)
Instantiates new configuration files
Updates the patch information files
Updates patch information and release version in the database

See: Testing a Patch Before Applying It.

Command Line Arguments

You can direct the way the AutoPatch operates by adding modifiers to the AutoPatch start command. These modifiers may be in the form of arguments or options. They refine the actions performed by AutoPatch.

Command line arguments and options are in the "token=value" format, where token is the name of the modifier. We recommend you enter both the argument and the value in lower case: AutoPatch automatically converts the "token" portion to lowercase, but it cannot convert the "value".

In this example:

$ adpatch LOGFILE=TEST.LOG

The token ("LOGFILE") will be converted to lowercase, but the value (TEST.LOG) will not be recognized by the utility. The correct way to enter this command is:

$ adpatch logfile=test.log

You can enter more than one token=value argument on a single command line by separating them with a single space, as in the following example.

$ adpatch printdebug=y flags=hidepw

In some cases, you can include more than one value for a token. When doing so, you separate the values with commas and no spaces. For example:

$ adpatch flags=nohidepw,trace

is a valid command, but

$ adpatch flags=nohidepw, trace

is not valid.

The following arguments are specific to AutoPatch, and can be used to modify and refine its behavior. The default value is used if you do not specify a value.

AutoPatch Arguments
Argument	Description
apply	Purpose: Tells AutoPatch whether to run in test mode. Values: y, meaning that AutoPatch does not run in test mode; n, meaning that AutoPatch does run in test mode. Default: y Example: adpatch apply=n
driver	Purpose: Tells AutoPatch the name of the patch driver file. This is usually used during non-interactive processing. It is only valid when the patchtop option is also used. Values: A driver file name, or comma-separated list of patch driver file names. Default: None, meaning that AutoPatch prompts for the patch driver file name. Example: adpatch patchtop=/d01/prodappl/patches/1234567 driver=u1234567.drv
patchtop	Purpose: Tells AutoPatch the top-level directory for the current patch. This is normally used during non-interactive processing. Values: A fully qualified directory name. Default: None, meaning that AutoPatch prompts for the patch directory. Example: adpatch patchtop=/d01/prodappl/patches/1234567
preinstall	Purpose: Tells AutoPatch whether to run in pre-install mode. Pre-install mode is used to update AD utilities before an upgrade and to apply pre-upgrade patches. Values: y, meaning that AutoPatch does run in pre-install mode; n, meaning that AutoPatch does not run in pre-install mode. Default: n Example: adpatch preinstall=y
uploadph	Purpose: Tells AutoPatch to upload patch history information from the patch information files (in $APPL_TOP/admin/$TWO_TASK) to the database. AutoPatch exits after uploading the patch history information. Values: y, meaning that AutoPatch uploads patch history information; n, meaning that AutoPatch does not upload patch history information. Default: none Example: adpatch uploadph=y

AutoPatch Options

The options= argument is used to pass generic options to AutoPatch. It takes the form of a comma-separated list. Enter one option or a comma-separated list of options. For example, options=nocopyportion,nogenerateportion. As with AutoPatch arguments, there must be no space after the comma.

AutoPatch Options
Option	Description
autoconfig	Purpose: Tells AutoPatch to run AutoConfig automatically. Default: autoconfig Use options=noautoconfig if you are applying a number of patches in sequence and want to run AutoConfig once, after applying the last patch of the sequence. Comments: The more common method is to merge the patches first with AD Merge Patch.
checkfile	Purpose: Tells AutoPatch to either skip running EXEC, SQL, and EXECTIER commands if they are recorded as already run, or to record them as having run after running them. Default: checkfile Use options=nocheckfile to turn off the checkfile feature. Comments: checkfile provides significant performance benefits.
compiledb	Purpose: Tells AutoPatch to automatically compile invalid objects in the database after running actions normally found in the database portion of the driver. Default: compiledb for standard patches. nocompiledb for standard patch translations, documentation patches, and documentation patch translations. Use options=nocompiledb to save time when multiple non-merged patches are applied in a maintenance window. Comments: Merging multiple patches and applying a single merged patch is usually a better strategy.
compilejsp	Purpose: Tells AutoPatch whether to automatically compile out-of-date JSP files. JSP files are only compiled if the patch contains copy actions for at least one JSP file. Default: compilejsp for standard patches. nocompilejsp for standard patch translations, documentation patches, and documentation patch translations. Use options=nocompilejsp to save time when multiple non-merged patches are applied in a maintenance window. Comments: Merging multiple patches and applying a single merged patch is usually a better strategy.
copyportion	Purpose: Tells AutoPatch whether to run commands normally found in the copy portion of the driver. Default: copyportion Use options=nocopyportion to tell AutoPatch not to perform copy actions of the driver.
databaseportion	Purpose: Tells AutoPatch whether to run commands normally found in the database portion of the driver. Default: databaseportion Use options=nodatabaseportion to tell AutoPatch not to perform database actions. of the driver
generateportion	Purpose: Tells AutoPatch whether to run commands normally found in the generate portion of the driver. Default: generateportion Use options=nogenerateportion to tell AutoPatch not to perform generate actions of the driver.
hotpatch	Purpose: Tells AutoPatch to apply a patch regardless of whether the Oracle E-Business Suite system is in Maintenance mode. AutoPatch aborts the patching session if Maintenance mode is disabled and the options=hotpatch command is not used. Default: nohotpatch
integrity	Purpose: Tells AutoPatch whether to verify that the version of each file referenced in a copy action matches the version present in the patch. Default: nointegrity Comments: Using options=nointegrity is safe and avoids some AutoPatch overhead.
maintenancemode	Purpose: Tells AutoPatch to enable Maintenance mode at the beginning of a patch session and disable it at the end (if patch application was successful). Default: nomaintenancemode The maintenancemode and hotpatch options cannot be used together. If they are, AutoPatch will raise the error ‘You cannot specify both "hotpatch" and "maintenancemode" in the same adpatch run’.
parallel	Purpose: Tells AutoPatch whether to run actions that update the database in parallel (such as SQL) and actions that generate files in parallel (such as genform). Default: parallel Comments: Oracle does not recommend changing the default, as Oracle E-Business Suite patches are tested on systems using parallel processing.
phtofile	Purpose: Tells AutoPatch where to place patch history information after applying the patch. Default: nophtofile Use options=phtofile to tell AutoPatch to write patch history information to the patch information files in the file system ($APPL_TOP/admin/$TWO_TASK) instead of uploading it to the database. Comments: Using phtofile allows you to defer the uploading of patch history information to the database until after the system downtime. Use the adpatch uploadph=y command to upload patch history information from the patch information files (in $APPL_TOP/admin/$TWO_TASK) to the database during uptime.
validate	Purpose: Tells AutoPatch whether to connect to all registered Oracle E-Business Suite schemas at the start of the patch. Default: novalidate Use options=validate to validate password information for all Oracle E-Business Suite schemas. Comments: Useful for finding problems with incorrectly registered Oracle E-Business Suite schemas or schemas with invalid passwords.

The AutoPatch Interface

AutoPatch is run from the command line. It prompts for any information required.

Running AutoPatch

The following is a summary of the steps you use to run AutoPatch. For a complete procedural description of all the steps, see Creating Customized Instructions for Patching Using PAA.

Step 1: Set the environment

You must set the environment to apply the configuration parameters that define your system. This task is common to many AD utilities.

Step 2: Unzip the patch

Create a patch top directory, if it does not already exist. Download the patch into the patch top directory and unzip it.

Step 3: Review the information in the readme file

In the directory where you unzipped the patch, you will find a README.txt file and a README.html file. Review either readme file for information about the patch and for instructions on using Oracle Patch Application Assistant (PAA) to generate customized instructions for your system.

Step 4: Run Oracle Patch Application Assistant

Run PAA (admsi.pl) to generate customized instructions for your system. Follow the steps in the customized instructions to start the patching process.

Step 5: Run AutoPatch

The customized instructions generated by PAA describe how to run AutoPatch using the adpatch command.

Note: You can add arguments on the command line to refine the way AutoPatch runs. See AutoPatch Modes and Command Line Arguments.

Stopping AutoPatch

You can stop AutoPatch by entering the abort command at any prompt. However, after the workers have started running, you can only stop AutoPatch by shutting down the workers in AD Controller.

Note: For detailed instructions on shutting down workers, see: Exiting or Stopping a Utility, Oracle E-Business Suite Maintenance Utilities.

Restarting AutoPatch

If you have shut down the workers, or if AutoPatch quits while performing processing actions, it saves all the actions completed up to that point in restart files. Investigate and resolve the problem that caused the failure, then restart AutoPatch. After you restart AutoPatch, it will ask if you want to continue with the previous session (at the point where the processing stopped), or start a new session.

See: Restarting a Utility, Oracle E-Business Suite Maintenance Utilities.

AD Merge Patch

When patches are applied individually, AutoPatch tasks such as responding to prompts and linking executables must be performed separately for every patch. This can be time-consuming and prone to error.

An alternative is to use AD Merge Patch. This utility merges multiple patches into a single patch, allowing you to reduce patch application time by eliminating the tasks you would otherwise have to have performed for each individual patch.

When merging compatible patches, AD Merge Patch bases its actions on metadata. It removes duplicate driver lines from the database portions of the driver. When merging two or more patches that have manual steps, the steps and readme files of both patches are also merged.

Source and Destination Directories

You extract the patches to be merged from the source directory. The destination directory is where the merged patch is created. AD Merge Patch reads the patch driver files for each patch in the source directory and merges them to create patch driver files in the destination directory. If a file exists in more than one source patch, only the highest revision of the file is copied to the destination directory.

The source and destination directories should be created under the same parent directory. For example, if the parent directory is named <top>, both the source and destination directories should be subdirectories of <top>. The source and the destination directories cannot be child or parent directories of each other.

Directory Structure for Source and Destination Directories - Basic Example

the picture is described in the document text

The source directory must have all patches to be merged as immediate child directories. The patch directories cannot be in a lower directory. For example, a directory structure for merging four patches would look like this:

Directory Structure for Source and Destination Directories - Merging Four Patches

the picture is described in the document text

Naming the Merged Patch

You should ndicate the name of the merged patch on the command line, using the -merge_name option to provide a meaningful name. If you do not use this option, the patch will be given the default name of merged.

Merging Zipped Patches

The manifest file is a text file in which you document the location and names of the patch zip files. The contents of a manifest file resembles the following:

/d01/prodappl/patches/p3903945_12_GENERIC.zip
/d01/prodappl/patches/p3892799_12_GENERIC.zip
/d01/prodappl/patches/p3874740_12_LINUX.zip

You can use the -manifest option to create a manifest file. AD Merge Patch references this file, and unzips the patches listed. It copies the unzipped files into the source directory and includes them, along with any other files in the source directory, in the merged patch.

The AD Merge Patch Interface

You run AD Merge Patch and supply the information it needs from the command line. There are no menus or input screens.

Running AD Merge Patch

AD Merge Patch is located in the AD_TOP/bin directory. However, you run it from the parent directory (<top>) of the source directory. The following is a summary of the steps you use to run AD Merge Patch. For a complete description of all the steps, see Creating a Merged Patch.

Step 1: Set the environment

You must set the environment to indicate the location of the configuration parameters that define your system. This task is common to many AD utilities.

Step 2: Run AD Merge Patch

From the parent directory (<top>), run AD Merge patch using the admrgpch command.

AD Merge Patch Enhancements

An upgrade from Release 11i to 12.1.1 could require the use of files that were not included in the upgrade itself. AD Merge Patch can merge the upgrade driver with fixes that were released after it was shipped, in effect providing a single highwatermark driver.

Several other recent AD Merge Patch enhancements take the form of command line options, which are described below and followed by examples.

-driveronly

This option is used to merge only the patch driver files present in the patch tops. AD Merge Patch will merge the actions present in the patch driver files, and write the merged content to the resulting patch driver file. However, the files will not be copied from the source directory to the destination directory. The resulting merged patch driver file will be placed in the destination directory given with the -d option.

-preinstall

This option is used to run AD Merge Patch in pre-install mode, where it will only merge the patch driver files present in the $APPL_TOP/admin/$TWO_TASK/preinstall directory. The -preinstall option implicitly enables the -driveronly option, and takes the source directory as $APPL_TOP/admin/$TWO_TASK/preinstall directory.

The -s option can be used in conjunction with the -preinstall option to specify the source directory and merge critical driver files. As pre-install upgrade driver files are copied to the pre-install directory when AutoPatch is used in pre-install mode, the combination of these options merges pre-install upgrade driver files with the master upgrade driver file.

The -preinstall option means that there are associated changes in how AutoPatch is used. These are described in Pre-Install Mode.

-master

This option is used to specify the master upgrade driver that is to be merged with the pre-install upgrade drivers. It is only valid with the -preinstall or -driveronly options.

-admode

AD Merge Patch is now restricted to merge either AD-only patches or non-AD patches. By default, AD Merge Patch will run in non-AD mode unless the –admode option is specified. In non-AD mode, AD Merge Patch will merge the non-AD patches present in either the source directory specified by the -s option, or the pre-install directory if -preinstall is specified.

Note: When merging patches, AD patches present in the source directory are ignored in non-AD mode.

Examples

Merging the non-AD patch driver files that are present under the patchtop:

admrgpch -s source -d dest -driveronly

Merging the non-AD patch driver files with the non-AD upgrade driver file found under upg:

admrgpch -s source -d dest -driveronly –master upg/upgrade.drv

Merging non-AD patch driver files present in the "preinstall" directory with non-AD upgrade driver files, in pre-install mode:

admrgpch -preinstall -d dest -master upg/upgrade.drv

Merging AD patch driver files with AD upgrade driver files in pre-install mode:

admrgpch -preinstall -d dest -master upgrade/upgrade.drv –admode