Search Results ad_patch_run_bug_actions_s

Overview

AD_FILE_UTIL is a utility package in the APPS schema of Oracle E-Business Suite, classified in the ETRM as a UTIL-type API. Its principal business function is to centralize the low-level file, patch, and snapshot infrastructure operations required by the Oracle Applications patch and maintenance utilities (notably the AutoPatch and AD utilities stack). Rather than each patching program independently querying and mutating the AD_FILES, AD_FILE_VERSIONS, and AD_CHECK_FILES families of tables, AD_FILE_UTIL provides a controlled API layer for loading, timestamping, and locking that data.

The package body is reported as VALID in the ETRM documentation for both the 12.1.1 and 12.2.2 codelines, meaning its compiled state is intact and it can be resolved at runtime. The metadata confirms eighteen documented procedures or functions, all oriented toward infrastructure locking and toward loading information into temporary and staging tables used during patch application, snapshot creation, and pre-install (prep) mode validation.

Key Procedures and Functions

The documented entry points group naturally into three functional areas.

• Infrastructure locking: LOCK_INFRASTRUCTURE and UNLOCK_INFRASTRUCTURE acquire and release the AD infrastructure lock (implemented with DBMS_LOCK, referenced in the dependency list), serializing patch and maintenance activity. LOCK_AND_EMPTY_TEMP_TABLE combines lock acquisition with truncation of a staging table.
• Data loading: LOAD_FILE_INFO, LOAD_FILE_VERSION_INFO, LOAD_CHECKFILE_INFO, LOAD_PATCH_ONSITE_VERS_INFO, and LOAD_SNAPSHOT_FILE_INFO populate the AD_FILES, AD_FILE_VERSIONS, AD_CHECK_FILES, and snapshot work tables with on-site version and check-file data. LOAD_PRESEEDED_BUGFIXES, LOAD_PATCH_HIST_ACTION, LOAD_PREPMODE_CHECKFILE_INFO, and LOAD_SNPST_FILE_SERVER_INFO support bugfix seeding, patch-history action records, prep-mode validation, and snapshot file-server metadata respectively.
• Temporary-table management and views: POPULATE_SNAPSHOT_FILES_TEMP and POPULATE_SNAPSHOT_BUGS_TEMP build snapshot staging content; CLN_PREPMODE_CHECKFILE_INFO cleans prep-mode staging data; UPDATE_TIMESTAMP maintains the AD_TIMESTAMPS bookkeeping row; and CREATE_GLOBAL_VIEW dynamically constructs a global view over the loaded file information.

All eighteen are documented by name only in the ETRM; parameter signatures are not published and should be obtained from the deployed package specification.

Tables Accessed

AD_FILE_UTIL references the file and filesystem metadata tables AD_FILES, AD_FILES_S, AD_APPL_TOPS, AD_APPL_TOPS_S, AD_FILE_VERSIONS, and AD_FILE_VERSIONS_S, which together describe application tops, translated file names, and per-file version history. The patch and bug tables AD_BUGS, AD_BUGS_S, AD_PATCH_COMMON_ACTIONS, AD_PATCH_COMMON_ACTIONS_S, AD_PATCH_RUN_BUGS, AD_PATCH_RUN_BUGS_S, AD_PATCH_RUN_BUG_ACTIONS, AD_PATCH_RUN_BUG_ACTIONS_S, and AD_PATCH_HIST_TEMP record bugfix and patch-execution state. The validation and snapshot tables AD_CHECK_FILES, AD_CHECK_FILES_S, AD_CHECK_FILE_TEMP, AD_CHECK_FILE_HISTORY, AD_PREPMODE_CHECK_FILES, AD_SNAPSHOTS, AD_SNAPSHOTS_S, AD_SNAPSHOT_BUGFIXES, AD_SNAPSHOT_BUGFIXES_S, AD_SNAPSHOT_FILES, and AD_SNAPSHOT_FILES_S store file-comparison results and snapshot contents. AD_RELEASES and the AD_TIMESTAMPS rows supply release and freshness context, while FND_PRODUCT_GROUPS and FND_STATS provide environment identification and statistics. In addition to DBMS_LOCK, the body depends on DBMS_STANDARD and DBMS_STANDARD equivalents under PUBLIC/SYS.

Usage Notes

AD_FILE_UTIL is an internal infrastructure package rather than an end-user or developer-facing API. It is invoked indirectly by Oracle Applications maintenance programs — AutoPatch (adpatch), the AD snapshot and file-comparison utilities, and prep-mode validation logic — during patch application, snapshot generation, and file-integrity checks. The absence of any inbound references from other database objects in the ETRM dependency listing indicates it is called from external AD utilities and command-line tooling rather than from PL/SQL callers. Custom code should not call these procedures directly; the locking routines in particular must be coordinated with the standard AD session conventions. Implementations should treat the eighteen procedures as version-sensitive across 12.1.1 and 12.2.2 and confirm signatures against the deployed specification before use.