Developer 6i Patch Set 19 upgrade with EBS 11i

It has been more than two years since the last Developer 6i patchset 18 was certified with Oracle E-Business Suite Release 11i, and now, Developer 6i patchset 19 (6.0.8.28) is certified with Oracle Apps 11i. Actually, since we migrated from Jinitiator to Java JRE 1.6, we've encountered some frustrating mouse focus issues, I really hope they were fixed with this patch and won't appear after upgrade. Like with the last patch set, I'll bring you "step-by-step" upgrade instructions for linux deployments. Other Operation Systems's need another patches - see Note 125767.1 - Upgrading Developer 6i with Oracle Applications 11i. *** All patches must be installed on all Application tier nodes Stop all application processes by adstpall.sh   Apply the latest certified Developer 6i patch set 19 (6194129)  - Source applications environment (e.g source .../testappl/APPSORA.env)  - Verify that $ORACLE_HOME is the 806_ORACLE_HOME - Execute with applmgr user $ unzip p6194129_60828_LINUX.zip $ cd developer6i_patch19 $ ./patch_install.sh 2>&1 | tee patch_install_p19.log         - Check patch_install_p19.log for any errors - Execute the following to relink Procedure Builder, Forms, Graphics and Reports $ cd $ORACLE_HOME/procbuilder60/lib; make -f ins_procbuilder.mk install $ cd $ORACLE_HOME/forms60/lib;       make -f ins_forms60w.mk install $ cd $ORACLE_HOME/graphics60/lib;    make -f ins_graphics60w.mk install $ cd $ORACLE_HOME/reports60/lib;     make -f ins_reports60w.mk install           Apply patch 7156414  - Unzip patch file $ unzip p7156414_60828_GENERIC.zip         - Backup old files $ cp -r $ORACLE_HOME/forms60/java/oracle/forms/handler/UICommon.class $ORACLE_HOME/forms60/java/oracle/forms/ handler/UICommon.class.PRE_BUG7156414 $ cp -r $ORACLE_HOME/forms60/java/oracle/forms/handler/ComponentItem.class $ORACLE_HOME/forms60/java/oracle/forms/ handler/ComponentItem.class.PRE_BUG7156414 $ cp -r $ORACLE_HOME/forms60/java/oracle/forms/handler/BlockScroller.class $ORACLE_HOME/forms60/java/oracle/forms/ handler/BlockScroller.class.PRE_BUG7156414 $ cp -r $ORACLE_HOME/forms60/java/oracle/forms/handler/FormCanvas.class $ORACLE_HOME/forms60/java/oracle/forms/ handler/FormCanvas.class.PRE_BUG7156414 $ cp -r $ORACLE_HOME/forms60/java/oracle/forms/handler/FormWindow.class $ORACLE_HOME/forms60/java/oracle/forms/ handler/FormWindow.class.PRE_BUG7156414 $ cp -r $ORACLE_HOME/forms60/java/oracle/forms/ui/VBean.class $ORACLE_HOME/forms60/java/oracle/forms/ ui/VBean.class.PRE_BUG7156414          - Copy patch files to appropriate directories $ cd [PATCH_TOP]/7156414/oracle/forms/handler $ cp UICommon.class      $ORACLE_HOME/forms60/java/oracle/forms/handler/UICommon.class $ cp ComponentItem.class $ORACLE_HOME/forms60/java/oracle/forms/handler/ComponentItem.class $ cp BlockScroller.class $ORACLE_HOME/forms60/java/oracle/forms/handler/BlockScroller.class $ cp FormCanvas.class    $ORACLE_HOME/forms60/java/oracle/forms/handler/FormCanvas.class $ cp FormWindow.class    $ORACLE_HOME/forms60/java/oracle/forms/handler/FormWindow.class $ cd [PATCH_TOP]/7156414/oracle/forms/ui $ cp VBean.class         $ORACLE_HOME/forms60/java/oracle/forms/ui/VBean.class - Regenerate Jar files   - Execute adadmin   - Select the "Generate Applications Files menu" option   - Select "Generate product JAR files"   - Do you wish to force regeneration of all jar files? => Yes   - Spot check that the JAR files have been generated by verifying the timestamp     $ cd $OA_JAVA/oracle/apps/fnd/jar $ ll fndforms.jar fndewt.jar           Apply patch 6125732 - Unzip patch file + Apply patch $ unzip p6125732_60828_LINUX.zip $ cd 6125732 $ sh patch.sh         Apply patch 6857221 - Unzip patch file + Apply patch $ unzip p6857221_60828_LINUX.zip $ cd 6857221 $ sh patch.sh         - Relink f60webmx for Oracle Applications $ adrelink.sh force=y "fnd f60webmx"         Apply patch 3830807 - Unzip patch file + Apply patch $ unzip p3830807_8063_LINUX.zip $ cd 3830807 $ ./patch.sh         - Relink all Applications executables:   adadmin -> "Maintain Applications Files" -> "Relink Applications programs"   Apply patch 4586086 - Unzip patch file $ unzip p4586086_600_LINUX.zip         - Backup old file $ cd $ORACLE_HOME/forms60/lib $ mv env_forms60.mk env_forms60.mk.PRE_BUG4586086         - Copy patch file to the appropriate directory $ cd [PATCH_HOME]/bug4586086 $ cp env_forms60.mk $ORACLE_HOME/forms60/lib - Generate shared object + Relink f60webmx for apps $ cd $ORACLE_HOME/forms60/lib $ make -f cus_forms60w.mk libso_install $ adrelink.sh force=y "fnd f60webmx"          Relink applications executables - Run adadmin - Select (2) "Maintain Applications Files Menu" - Select (1) "Relink Applications programs" - List of product to link: fnd - Generate specific executables …: Yes - Relink with debug: No - Enter executables to relink: f60webmx ar60run ar60runb ar60rund   Apply patch 7343387 (Apps Interoperability) - Unzip patch file $ unzip p7343387_11i_GENERIC.zip         - Enable maintenance mode: adadmin -> (5) Change Maintenance Mode -> (1) Enable Maintenance Mode - apply patch with adpatch - Disable maintenance mode: adadmin -> (5) Change Maintenance Mode -> (2) Disable Maintenance Mode   Verify your upgrade - Check the timestamp for the following files: $ cd $OA_JAVA/oracle/apps/fnd/jar $ ll fndforms.jar fndewt.jar          If the timestamp is not current - run adadmin => Maintain Applications Files => Generate Product JAR Files.    Start all applications processes (adstrtall.sh) - You can also verify your upgrade by login to forms responsibility -> Help -> About Oracle Applications   You should see: Oracle Forms version : 6.0.8.28.0   Related - Note 125767.1 - Upgrading Developer 6i with Oracle Applications 11i. You are welcome to leave a comment

FND_GLOBAL affected by New Global Performance Changes

After applying ATG Rollup 5 patch (and above) we discovered an issue with some of our custom developments. For some processes we got the following errors: ORA-20001: Oracle error -20001: ORA-20001: Oracle error -4092: ORA-04092: cannot SET NLS in a trigger has been detected in fnd_global.set_nls.set_parameter('NLS_LANGUAGE','AMERICAN'). has been detected in fnd_global.set_nls. ORA-06512: at "APPS.APP_EXCEPTION", line 72 ORA-06512: at "APPS.FND_GLOBAL", line 240 ORA-06512: at "APPS.FND_GLOBAL", line 1410 ORA-06512: at "APPS.FND_GLOBAL", line 1655 ORA-06512: at "APPS.FND_GLOBAL", line 2170 ORA-06512: at "APPS.FND_GLOBAL", line 2312 ORA-06512: at "APPS.FND_GLOBAL", line 2250 and this: ORA-20001: Oracle error -2074: ORA-02074: cannot SET NLS in a distributed transaction has been detected in fnd_global.set_nls.set_paramenters('NLS_LANGUAGE','AMERICAN'). After some debug work we found that this issue happens when executing FND_GLOBAL.apps_initialize more than once within a trigger/via a db link in the same transaction. According to Note: 556391.1 - "ORA-02074: Cannot SET NLS in a Distributed Transaction" this issue cause by a new global performance changes. Oracle Development said: "Very sorry if the new global performance changes have exposed you to this error, but there is no way we can back out these changes. They are not only complex and wide spread but required to maintain functional performance levels. Using fnd_global to change user/resp context from a trigger is not only not supported it is ill advised." OK, So we had to find a workaround to this issues and we found two... I'll start with a sample of the new behavior of fnd_global to demonstrate the issue and the solutions/workarounds will come right after. SQL> create table test1 (a number, b number); Table created SQL> insert into test1 (a) values (1001); 1 row inserted SQL> insert into test1 (a) values (1002); 1 row inserted SQL> commit; Commit complete SQL> create or replace trigger test1_trg_bi   2  after update on test1   3  for each row   4  begin   5       fnd_global.APPS_INITIALIZE(:new.a,1,1);   6       -- fnd_request.submit_request...   7       -- ....   8       -- ....   9  end; 10  / Trigger created SQL> select fnd_global.user_id from dual;     USER_ID ----------         -1 SQL> update test1 set b=1101 where a=1001; 1 row updated SQL> select fnd_global.user_id from dual;     USER_ID ----------       1001 SQL> update test1 set b=1102 where a=1002; update test1 set b=1102 where a=1002 ORA-20001: Oracle error -20001: ORA-20001: Oracle error -4092: ORA-04092: cannot SET NLS in a trigger has been detected in fnd_global.set_nls.set_parameter('NLS_LANGUAGE','AMERICAN'). has been detected in fnd_global.set_nls. ORA-06512: at "APPS.APP_EXCEPTION", line 72 ORA-06512: at "APPS.FND_GLOBAL", line 240 ORA-06512: at "APPS.FND_GLOBAL", line 1410 ORA-06512: at "APPS.FND_GLOBAL", line 1655 ORA-06512: at "APPS.FND_GLOBAL", line 2170 ORA-06512: at "APPS.FND_GLOBAL", line 2312 ORA-06512: at "APPS.FND_GLOBAL", line 2250 ORA-06512: at "APPS.TEST1_TRG_BI", line 2 ORA-04088: error during execution of trigger 'APPS.TEST1_TRG_BI' As you can see, the second update failed because apps_initialize was executed for the second time in the same transaction. Now I'll show two ways to workaround this issue: 1) As suggested in Note: 556391.1 - "ORA-02074: Cannot SET NLS in a Distributed Transaction" a wrapper Concurrent Request which contain a call to the context set (apps_initialize) and afterwards submits the original request, is one possible solution. instead: create or replace trigger test1_trg_bi after update on test1 for each row declare      . . . begin      fnd_global.APPS_INITIALIZE(:new.a,1,1);      ret_code := fnd_request.submit_request ('OWNER', 'ORIGINAL_CONC', . . .);      . . .      . . . end; create the following trigger: create or replace trigger test1_trg_bi after update on test1 for each row declare      . . . begin      ret_code := fnd_request.submit_request ('OWNER', 'WRAPPER_CONC', . . . , :new.a, . . . );      . . .      . . . end; additionally - create a new plsql concurrent (WRAPPER_CONC) that contains the fnd_global.apps_initialize and submits the ORIGINAL_CONC concurrent request. This way, the apps_initialize statement executed in a separate transaction with no error. This is the preferred and recommended solution by Oracle. 2) The second solution is easier to implement, works fine but according to Note: 556391.1 is not supported since it contains calls to fnd_global within a database trigger. Anyway... The idea is to call the apps_initialize in an Autonomous Transaction procedure. Follow this sample: SQL> create or replace procedure test1_apps_init (p_user_id number) is   2  pragma autonomous_transaction;   3  begin   4       fnd_global.APPS_INITIALIZE(p_user_id,1,1);   5       commit;   6  end;   7  / Procedure created SQL> create or replace trigger test1_trg_bi   2  after update on test1   3  for each row   4  begin   5       test1_apps_init (:new.a);   6       -- fnd_request.submit_request...   7       -- ....   8       -- .....   9  end; 10  / Trigger created SQL> select fnd_global.user_id from dual;     USER_ID ----------         -1 SQL> update test1 set b=1101 where a=1001; 1 row updated SQL> select fnd_global.user_id from dual;     USER_ID ----------       1001 SQL> update test1 set b=1102 where a=1002; 1 row updated SQL> select fnd_global.user_id from dual;     USER_ID ----------       1002 As you can see, the update statements were executed successfully this time and the session was updated with the appropriate user context in each update statement. Those two solutions are working fine, but keep in mind that the second is not supported. You are welcome to leave a comment. Aviad

Upgrade from Jinitiator 1.3 to Java Plugin 1.6.0.x

Lately Oracle announced the end of Error Correction Support for Jinitiator 1.3 for E-Business Suite 11i, effective July 2009. This is the sign it’s about time to upgrade to the native Java Plug-in… :-) Among other things, one of the main advantages of upgrading from Jinitiator to the native Java Plug-in is the prevention of conflicts between them. This upgrade is great news to all are working with Oracle Discoverer Plus (with Java plug-in) and Oracle EBS 11i (with Jinitiator) and experiencing those conflicts. I’ll skip all the others advantages and disadvantages of upgrading to Java Plug-in as they are well described in Steven Chan’s post - Jinitiator 1.1.8 To Be Desupported for Apps 11i and in Metalink Note: 290807.1 - Upgrading Sun JRE with Oracle Applications 11i. So I will focus on the upgrade process itself - step by step. I tested the upgrade on the following test environment: EBS 11.5.10.2 Database 10.2.0.3 ATG Rollup 5 Developer 6i patchset 18 OS RHEL4. Be aware that before upgrading to Java Plug-in you must upgrade to Developer 6i patchset 18 or later (currently the latest patchset is 19). * You can use my previous post in order to Upgrading Developer 6i with Oracle Apps 11i to patchset 18. Download JRE plug-in Oracle E-Business Suite interoperability patch - 6863618 Download the Sun JRE Plug-in  Select Java Runtime Environment (JRE) 6 Update X (select the latest available update, currently it’s 5) Select Windows offline installation, multi-language Rename the downloaded installation file jre-6_uX-windows-i586-p.exe to j2se1600x.exe In my case rename jre-6_u5-windows-i586-p.exe to ==>> j2se16005.exe Copy the j2se1605.exe file to $COMMON_TOP/util/jinitiator on the Apps Tier node If you are on Developer 6i patchset 18 you should apply forms patches 6195758 & 5884875. ** Skip this step if you are on Developer 6i patchset 19. Download Patches 6195758 & 5884875 Apply patch 6195758 Stop all applications processes by adstpall.sh Unzip p6195758_60827_GENERIC.zip cd 6195758 cp -r $ORACLE_HOME/forms60/java/oracle/forms/ handler/UICommon.class $ORACLE_HOME/forms60/java/oracle/forms/ handler/UICommon.class.PRE_BUG6195758 cp -r $ORACLE_HOME/forms60/java/ oracle/forms /handler/ComponentItem.class $ORACLE_HOME/forms60/java/oracle/forms/ handler/ComponentItem.class.PRE_BUG6195758 cp oracle/forms/handler/UICommon.class $ORACLE_HOME/forms60/java/oracle/forms/ handler/UICommon.class cp oracle/forms/handler/ComponentItem.class $ORACLE_HOME/forms60/java/oracle/forms/ handler/ComponentItem.class Apply Patch 5884875 Unzip p5884875_60827_GENERIC.zip cd 5884875 cp -r $ORACLE_HOME/forms60/java/oracle/forms/engine/Main.class $ORACLE_HOME/forms60/java/oracle/forms/ engine/Main.class.PRE_BUG5884875 cp -r $ORACLE_HOME/forms60/java/ oracle/forms/ handler/AlertDialog.class $ORACLE_HOME/forms60/java/oracle/forms/ handler/AlertDialog.class.PRE_BUG5884875 cp oracle/forms/engine/Main.class $ORACLE_HOME/forms60/java/oracle/forms/engine/Main.class cp oracle/forms/handler/AlertDialog.class $ORACLE_HOME/forms60/java/oracle/forms/ engine/AlertDialog.class Run adadmin -> Generate Applications Files menu -> Generate product JAR files Apply the Interoperability patch 6863618 Make sure all applications processes are down Enable maintenance mode: Execute adadmin -> Change Maintenance Mode (5) -> Enable Maintenance Mode (1) Unzip p6863618_11i_GENERIC.zip Cd 6863618 Run adpatch to apply patch driver u6863618.drv cd [PATCH_NUMBER]/fnd/bin Execute the following command where X represent the update number: $ txkSetPlugin.sh 1600X In my case: $ txkSetPlugin.sh 16005 Disable maintenance mode: Execute adadmin -> Change Maintenance Mode (5) -> Disable Maintenance Mode (2) Start all applications processes by adstrtall.sh Verify installation by sign in Oracle EBS and select a forms based responsibility. For those who worry about performance, take a look at this benchmark: Benchmark comparison test with Jinitiator 1.3.1.23 and Java Plug-in 1.5.0_05 – performance whitepaper For more information - Note: 290807.1 - Upgrading Sun JRE with Oracle Applications 11i Aviad

UTL_FILE_DIR issue after applying patch 5985992 'TXK AUTOCONFIG RUP Q'

Do you have more than 240 characters in your utl_file_dir? if so, you should read this before applying patch 5985992 'TXK AUTOCONFIG RUP Q (Jul/Aug 2007)'. After applying this patch, AutoConfig on database tier failed with the following error: [PROFILE PHASE]   AutoConfig could not successfully execute the following scripts:     Directory: [RDBMS_ORACLE_HOME]/appsutil/install/[context_name]        afdbprf.sh              INSTE8_PRF         1 AutoConfig is exiting with status 1 It wasn't clear why afdbprf.sh failed so I ran it manually from ssh terminal and I got this: $ [RDBMS_ORACLE_HOME]/appsutil/install/[context_name]/afdbprf.sh afdbprf.sh started at Tue Jan 29 17:43:21 IST 2008 The environment settings are as follows ...        ORACLE_HOME : ....        .........        ......... Application Id : 0 Profile Name : BIS_DEBUG_LOG_DIRECTORY Level Id : 10001 New Value : /usr/tmp Old Value : /usr/tmp declare * ERROR at line 1: ORA-12899: value too large for column "APPLSYS"."FND_PROFILE_OPTION_VALUES"."PROFILE_OPTION_VALUE" (actual: 486, maximum: 240) ORA-06512: at line 44 ORA-06512: at line 139 Looking into afdbprf.sql  (executed by afdbprf.sh) reveals the problem: ....... --Setting  BIS_DEBUG_LOG_DIRECTORY            set_profile(0, 'BIS_DEBUG_LOG_DIRECTORY',                        10001, 0,                        '&BIS_DEBUG_LOG_DIR',                        NULL); -- This profile option was earlier set in addbprf.sql via bug 2843457, Now moved here for bug 5722442 -- -- Set up UTL_FILE_LOG profile option --           set_profile(1, 'UTL_FILE_LOG',                       10001, 0, '/usr/tmp,........[more than 240 characters..... :-) ]',                       NULL); In order to fix bug 5722442, the UTL_FILE_LOG updated with the value of s_db_util_filedir from the database context file and a new bug was created (not a bug according to Bug 6404909). If the s_db_util_filedir contains more than 240 characters it can't be stored in a profile since the PROFILE_OPTION_VALUE column defined as varchar2(240). The s_db_util_filedir initialized when creating the database context file by adbldxml.pl, and set up with the value of utl_file_dir database parameter. I'm not sure why it should be updated with all directories within utl_file_dir and not with the relevant directories only...?!  The UTL_FILE_LOG profile (or "Stored procedure log directory") wasn't updated with AutoConfig before applying this patch, so I'm not sure regarding the purpose of this profile. Before applying this patch I have this profile set to a directory that doesn't exist... The solution according to Note:458511.1 - "After patch 5985992 AutoConfig On Database Tier Fails with script afdbprf.sh" is to change the value of s_db_util_filedir in the database context file to a value less the 240 characters and run AutoConfig again. And it works, of course... What should I do if I my utl_file_dir contains more than 240 characters?! Actually I don't have a good answer to this question but I will try to locate all the places on which this issue might affect when s_db_util_filedir will be updated with a value less than 240 chars. AutoConfig on the DB Tier creates the [SID]_APPS_BASE.ora file under $RDBMS_ORACLE_HOME/dbs (if it's not already exist), which contains the utl_file_dir database parameter generated respectively to the s_db_util_filedir from the database context file. So if you plan to rebuild your init.ora with AutoConfig you will need to update the utl_file_dir manually. When executing adbldxml.pl on DB Tier to rebuild the database context file, the s_db_util_filedir will be filled with the utl_file_dir database parameter - that might contain more than 240 chars. Therefore, before executing AutoConfig you should edit the new context file and shorten the value of s_db_util_filedir. The UTL_FILE_LOG profile ("Stored procedure log directory")  will be updated with s_db_util_filedir shortened value. You are welcome to leave a comment or update with additional information regarding this issue. Aviad

How to get details about patch applied in Oracle Applications by OAM & SQL?

There are some tables in oracle apps (AD tables especially) involved when applying patches. Some of them are very useful when we need specific information about patch already applied. I will show the main tables and afterwards some handy related SQL’s to retrieve patch applied details and how we can also get all this information via OAM. AD_APPLIED_PATCHES – The main table when we are talking about patches that applied in Oracle Apps. This table holds information about the "distinct" Oracle Applications patches that have been applied. If 2 patches happen to have the same name but are different in content (e.g. "merged" patches), then they are considered distinct and this table will therefore hold 2 records (eTRM). I also found that if the applications tier node is separate from the concurrent manager node, and the patch applied on both nodes, this table will hold 2 records, one for each node. AD_PATCH_DRIVERS – This table holds information about all patch drivers included in specific patch. For example if patch contain only one unified driver like u[patch_name].drv then ad_patch_drivers will hold 1 record. On the other hand, if patch contain more than 1 driver, for example d[patch_name].drv and c[patch_name].drv, this table will hold 2 records. AD_PATCH_RUNS – holds information about each execution of adpatch for a specific patch driver. In case a patch contains more than one driver, this table will hold a record for each driver. This table also holds one record for each node the patch driver has been applied on (column APPL_TOP_ID). AD_PATCH_RUN_BUGS – holds information about all the bugs fixed as a part of specific run of adpatch. AD_BUGS – this table holds information about all bug fixes that have been applied. We have 2 options to view applied patch information: 1) via OAM – Oracle Applications Manager 2) Via SQL queries With OAM it’s easy and very intuitive, from OAM site map -> “Maintenance” tab -> “Applied Patches” under Patching and Utilities. Search by Patch ID will get all information about this patch; In addition, drill down by clicking on details will show the driver details. For each driver we can use the buttons (Timing Details, Files Copied, etc.) to get more detailed information. With SQL we can retrieve all the above information, sometimes more easily. For example: How to know which modules affected by specific patch? With OAM: 1) search patch by Patch ID 2) click on Details 3) For each driver click on “Bug Fixes” and look on product column. With SQL: Run the following query, it will show you all modules affected by specific patch in one click… select distinct aprb.application_short_name as "Affected Modules" from ad_applied_patches aap, ad_patch_drivers apd, ad_patch_runs apr, ad_patch_run_bugs aprb where aap.applied_patch_id = apd.applied_patch_id and apd.patch_driver_id = apr.patch_driver_id and apr.patch_run_id = aprb.patch_run_id and aprb.applied_flag = 'Y' and aap.patch_name = '&PatchName'; Another SQL will retrieve basic information regarding patch applied, useful when you need to know when and where (node) you applied specific patch: select aap.patch_name, aat.name, apr.end_date from ad_applied_patches aap, ad_patch_drivers apd, ad_patch_runs apr, ad_appl_tops aat where aap.applied_patch_id = apd.applied_patch_id and apd.patch_driver_id = apr.patch_driver_id and aat.appl_top_id = apr.appl_top_id and aap.patch_name = '&PatchName'; To check if specific bug fix is applied, you need to query the AD_BUGS table only. This table contains all patches and all superseded patches ever applied: select ab.bug_number, ab.creation_date from ad_bugs ab where ab.bug_number = '&BugNumber'; For any question or additional information you are welcome to leave a comment... Aviad

After ATG RUP 5 Concurrent Managers Fail to Start

Last week I have installed the ATG RUP 5 on my TEST environment. Everything goes smooth, all additional patche applied successfully, the application startup succesfully, great.... Today, I decide to make some order in this TEST environment and I run FND_CONC_CLONE.setup_clean to clean FND_NODES and all tables that refilled by autoconfig. Afterwards, autoconfig on DB tier and APPS tier. I checked the FND_NODES table and it looks like it populated successfully (without the old nodes from source environment...) I run the adstrtall script to startup apps tier and the Concurrent Managers didn't startup! The error mesasge I got was: Could not initialize the Service Manager FNDSM_[SERVER_NAME]_[ENV_NAME]. Verify that [SERVER_NAME] has been registered for concurrent processing. Routine AFPEIM encountered an error while starting concurrent manager.... The cause of this problem is the change of FNDSM trigger in ATG RUP 5. ==================================================== The new FNDSM trigger code is: CREATE OR REPLACE TRIGGER fndsm AFTER INSERT ON FND_NODES FOR EACH ROW BEGIN if ( :new.NODE_NAME <> 'AUTHENTICATION' ) then if ( (:new.SUPPORT_CP='Y') or (:new.SUPPORT_FORMS='Y') or (:new.SUPPORT_WEB='Y') ) then fnd_cp_fndsm.register_fndsm_fcq(:new.NODE_NAME); end if; if (:new.SUPPORT_CP = 'Y') then fnd_cp_fndsm.register_fndim_fcq(:new.NODE_NAME); end if; end if; END; ==================================================== When we run autoconfig on db tier, new row inserted into FND_NODES but FNDSM and FNDIM are not created since db tier not supported CP/FORMS/WEB. When we run autoconfig on apps tier, this columns are updated to 'Y' but FNDSM trigger is not run because it is fired for insert and not for update. The Solution is : 1) Recreate the FNDSM trigger same as before but add "AFTER INSERT OR UPDATE ON FND_NODES". 2) Run: exec FND_CONC_CLONE.setup_clean; (with apps) 3) Run autoconfig on db tier and apps tier (in this order) 4) Startup apps tier. There is no patch at this time to fix this probem, but when ATG RUP 6 will be available it will contain a fix to FNDSM trigger. Full details in Metalink note 434613.1. Cheers, Aviad

ADPATCH with "options=prereq" - what really happens there?

With adpatch utility we have a possibility to ask for a prerequisite check prior to running patch driver files. Actually, some patches must apply with prerequisite check before applying them. The adpatch command should look like: adpatch option=prereq This flag indicate to adpatch to check prerequisite before applying patch. adpatch checks the prerequisite based on information from patch files and current snapshot on APPL_TOP. When running adpatch with "prereq" flag, we might get an error message like: Analyzing prerequisite patch information... AutoPatch error: This patch has some prerequisites specified, but a "snapshot" of this APPL-TOP's file-system has never been taken, thereby rendering it impossible to check for the prerequisites. Please take a "snapshot" of this APPL-TOP using "AD Administration" first. This error message will show up if a snapshot on current APPL_TOP doesn't exists. To create such snapshot on APPL_TOP: 1) run adadmin 2) Select "Maintain Applications Files menu" 3) Select "Update current view snapshot" 4) Rerun adpatch **It might take couple of hours depends on your hardware and APPL_TOP size. So how adpatch check the prerequisites? 1) Check if a snapshot on current APPL_TOP exist. using sql script - adbkflsn.sql (if not, will terminate with above error message.....) 2) adpatch uploads a ldt file with FNDLOAD utility into system (bug-fixes). ldt file name is: b[PATCH_NUMER].ldt - comes from patch root directory. 3) Execute the UMS analysis engine based on the snapshot and bug-fixes to check if all prerequisites exists. You are welcome to leave a comment...