R12.2 Adop Patching Utilities

• 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

• The adop utility always runs from the run edition file system. It automatically sets its environment correctly, regardless of the edition it is run from. Editions are described in more detail later.
• If a patch contains no new updates to files or database objects in your system, adop takes no action.
• If adop detects a previously failed patching session, it will attempt to recover that session.

adop Parameters
Parameter	Purpose	Values	Comments
phase	Used to tell adop which phases it is to run.	prepare apply finalize cutover cleanup fs_clone abort actualize_all	You can use a comma-separated list to specify multiple phases. For example, 'phase=prepare,apply' Note: Neither the abort nor fs_clone phases can be specified with any other phase. If you supply a phase other than those listed, a usage statement will be printed and adop will exit.
loglevel	Used to specify the amount of information logged and displayed as adop performs its operations.	STATEMENT PROCEDURE EVENT WARNING ERROR UNEXPECTED	STATEMENT is only used for debugging. PROCEDURE is only used for debugging high level procedures. EVENT is used to display informational messages in normal processing. This is the default value. WARNING is used to indicate an internal error that is handled by the system and does not affect processing. ERROR indicates an action failed and will need to be reviewed by the user, but the system was able to continue processing. UNEXPECTED indicates an unrecoverable error that halts processing and requires user intervention before processing can continue.
apply_mode	Allows patches to be applied in downtime or hotpatch modes, by adding the relevant option to the adop phase=apply command.	online (default) downtime hotpatch	apply_mode=downtime applies the specified patches in downtime mode. When using this mode, you only run the apply phase. apply_mode=hotpatch applies the specified patches in hotpatch mode. When using this mode, you only run the apply phase. Important: You must only use the downtime and hotpatch modes when explicitly directed, for example by the patch readme.
cleanup_mode	Provides cleanup processing control.	quick full	cleanup_mode=quick performs minimum cleanup, which includes removal of crossedition triggers and obsolete seed data. cleanup_mode=full does the same as standard mode, and also drops obsolete columns and old editions.
finalize_mode	Specifies the processing to be performed in the finalize phase.	full quick	finalize_mode=full gathers statistics to help improve performance. If you specify this mode, allow extra time (about an hour) for finalize to complete. finalize_mode=quick does not gather statistics, and therefore completes more quickly. This is the default.
input_file	Used to specify the name of the input_file supplied to adop.	User-specified.	Must be an absolute file path.
maxworkers	Used to override the default formula calculation for the number of workers.	User-specified.	For example, if the default calculation gives 30 workers, but the desired number of workers is 50, adop can be run by specifying workers=50 maxworkers=60 maxworkers should always be set to greater than the desired number of workers, so the default value is overridden.
patches	Used to specify the patches adop is to apply.	User-specified. Patches can be specified in two ways: <Patch Number>: For example, to apply patch number 123456 you would specify 'patches=123456'. <Patch Directory>: <Patch Driver File>: For example, to apply the Korean language translation for patch 123456 you would specify 'patches=123456_KO:u123456.drv'. Note that patch directory is relative to the $PATCH_TOP.	You can use a comma-separated list to specify that multiple patches are to be applied in the same patching operation. The numbered-only and containing-a-colon categories of patch can be mixed. For example, you would specify patch number 111 and the Korean language version of patch 222 as 'patches=111,222_KO:u222.drv'.
hotpatch	Specifies whether the patches are to be applied in hotpatch mode. Note: This parameter has been superseded by the apply_mode parameter and is only retained for backward compatibility.	yes/no	hotpatch=yes applies the specified patches to the run edition while this edition is in active use. Important: You must only use hotpatch mode when explicitly directed, for example by the patch readme. You cannot abort application of a patch applied in hotpatch mode.
flags	Used to specify numerous options. To see a full list, enter: $ adop -examples The flags typically exist in pairs, such as autoskip/noautoskip	: Using the example of autoskip/noautoskip: this pair of flags is used to specify whether adop should quit if there is a driver action failure when applying a patch.	Using the example of autoskip/noautoskip: the default is noautoskip (quit processing). You can force processing to continue by specifying flags=autoskip on the command line or in the input file.
prompt	Specifies whether adop prompts the user whether to continue after warnings.	yes/no	Default is 'yes' (prompt the user). Set prompt=no to enable fully non-interactive mode, in which adop will continue past warning messages without user confirmation.
options	Used to specify various options during the apply phase. See the "adop Options" section later this chapter.	option-specific	Refer to individual options.
cm_wait	Can be used when running cutover to specify how long to wait for existing concurrent processes to finish running before shutting down the Internal Concurrent Manager.	User-specified integer representing number of minutes to wait. By default, adop will wait indefinitely for in-progress concurrent requests to finish.	Oracle recommends the following settings: On production systems, do not specify cm_wait, but monitor progress of concurrent tasks and take manual action on them if needed. On non-production systems, specify cm_wait to limit the waiting time before cutover proceeds.
workers	Used to specify the number of parallel workers to be employed.	User-specified integer.	If you omit the 'workers' argument, a suitable number of workers will be be chosen automatically. If you specify more workers than the machine can handle, adop will exit with an error.
defaultsfile	Used to specify the path to the custom adop defaults file.	User-specified (but has a default value - see next column).	Must be an absolute file path. Defaults to $APPL_TOP/admin/$TWO_TASK if not specified by user.
patchtop	Used to specify the location where the patches are unloaded.	User-specified (but has a default value - see next column).	Must be an absolute file path. Defaults to $APPL_TOP_NE/EBSapps/patch if not specified by user.
merge	Used to merge multiple patches. You can merge the unified driver files into a single driver file that is passed to adop.	yes/no	If merge is set to the default of 'no', then the patches are applied sequentially in the order listed. You can set the merge parameter to 'yes' in order to merge a base patch with any required corrective patches, so that the corrected merge patch is applied as a single operation.
abandon	Specify whether to abandon a previous failed attempt to apply a patch. Use this mode if you want to continue with the online patching actions even though a patch apply has failed. Note: If there was an error in the previous run, and 'abandon' is not set to 'yes', the same parameters will be re-used that were used in the failed run.	yes/no	Default value is 'no'. You cannot set the abandon parameter to 'yes' if the restart parameter is also set to 'yes'.
restart	Specify if the previous failed patch apply should be restarted. This allows you to retry applying the previous patch from where it left off. This is useful if you were able to correct the cause of the error and want patch application to continue executing.	yes/no	Default value is 'no'. You cannot set the restart parameter to 'yes' if the abandon parameter is also set to 'yes'.
skipsyncerror	Enables the user to specify that any synchronization errors in the prepare phase are expected to be fixed automatically in the synchronization that takes place with subsequent patches.	yes/no	Default value is 'no'. Set the value to 'yes' in order to work around synchronization failures that may occur when patches that failed to apply correctly in a previous patching cycle are synchronized during the prepare phase.
mtrestart	Used to specify whether to restart application tier services after cutover.	yes/no	Default value is 'yes'. If 'no' is specified, the services can later be restarted with the the adstrtal utility.
allowcoredump	Used to specify that a core dump should be generated if adop crashes.	yes/no	Default value is 'no'. A value of 'yes' should be specified only if diagnostic information needs to be gathered.
analytics	Used to generate reports that can be helpful in debugging certain types of issue. Available with apply, finalize, cutover, and cleanup adop phases.	yes/no	Default value is 'no'. A value of 'yes' should be specified only if reports specifically need to be generated. This is because of the extra processing overhead involved.

1. Command Line: An adop parameter specified on the command line will take precedence over all others.
2. Input File: An adop parameter given here will only be lower in precedence to a parameter specified on the command line.
3. Defaults File: Parameters defined here have the lowest level of precedence.

Non-adop AD Log Files
Log File	Used For
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

• 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:

• 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).

• 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, adop runs scripts and commands in parallel.
• Compiles invalid objects in the database.
• Assembles a list of current invalid objects in the APPS schema.

• 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

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

• To run a patching cycle, and test patch application without actually taking any apply actions, in test mode
• To apply patches outside a patching cycle in downtime mode
• To apply patches without connecting to the database in preinstall mode

• Copy files from the patch directory to the Oracle E-Business Suite file system
• Archive object modules into the product libraries
• Relink executables
• Generate forms, reports, PL/SQL libraries, or menu files
• Run SQL or EXEC commands (commands that change the database)
• Instantiate new configuration files
• Update the patch information files
• Update patch information and release version in the database

• Release 12.2 patches are not normally tested in downtime mode.
• Downtime mode is only supported for production use where explicitly documented, or when directed by Oracle Support or Development.

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

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

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

adop Options
Option	Description
actiondetails	Purpose: Tells adop to print details of actions taken in a patching operation. Default: actiondetails Specify options=noactiondetails if you do not want the details to be printed. Comments: It is generally preferable to accept the default, as the action details can be useful in understanding adop operations and diagnosing issues.
autoconfig	Purpose: Tells adop 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 dual file system in Release 12.2 means that there is no need to shut down application tier services before running AutoConfig.
checkfile	Purpose: Tells adop 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: This option is currently not supported unless explicitly documented in the patch readme. If you are reapplying a patch with options=nocheckfile and the patch contains a call for a seed table upgrade (AD_ZD_SEED.UPGRADE), you may receive the error message "ORA-20001: Cannot upgrade existing table from Patch Edition". You can safely ignore this message if the table already contains the column 'ZD_EDITION_NAME'.
compiledb	Purpose: Tells adop 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 the same patching operation. Comments: Merging multiple patches and applying a single merged patch is usually a better strategy.
compilejsp	Purpose: Tells adop 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 adop whether to run commands normally found in the copy portion of the driver. Default: copyportion Comments: Use options=nocopyportion to tell adop not to perform copy actions of the driver.
databaseportion	Purpose: Tells adop whether to run commands normally found in the database portion of the driver. Default: databaseportion Comments: Use options=nodatabaseportion to tell adop not to perform database-related driver actions.
forceapply	Purpose: Tells adop to reapply a patch that has already been applied. Default: noforceapply Comments: Use the nocheckfile option in conjunction with forceapply to rerun files which may already have been executed. If you try to apply a patch that has already been applied and do not specify the forceapply parameter, adop will display an error like this:  [WARNING] Skipping the application of patch 14125999_AR since it has been already applied [WARNING]  Hint: Patches can be applied again by specifying options=forceapply when invoking adop
generateportion	Purpose: Tells adop whether to run commands normally found in the generate portion of the driver. Default: generateportion Use options=nogenerateportion to tell adop not to perform generate actions of the driver.
integrity	Purpose: Tells adop 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 adop overhead.
parallel	Purpose: Tells adop 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 fully tested using this option.
phtofile	Purpose: Tells adop where to place patch history information after applying the patch. Default: nophtofile Use options=phtofile to tell adop 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.
validate	Purpose: Tells adop 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.

• If you want information about a particular session, specify the relevant session ID:

• If you want additional details of operations performed:

• If you want to restart a failed patch from where it left off, you only need to specify restart=yes on the command line:

• If you want to restart a failed patch from the very beginning, you need to specify abandon=yes on the command line:

• If you want to ignore a previously failed patch and apply a different one instead, you need to specify the new patch number and abandon=yes on the command line: