txkGenADOPWrapper.pl line 143 ) ERRORCODE = 1 ERRORCODE_END
WARNING: [AutoConfig Error Report]
The following report lists errors AutoConfig encountered during each
phase of its execution. Errors are grouped by directory and phase.
The report format is:
<filename> <phase> <return code where appropriate>
[INSTANTIATE PHASE]
AutoConfig could not successfully instantiate the following files:
Directory: /u01/app
EBSapps.env INSTE8
[APPLY PHASE]
AutoConfig could not successfully execute the following scripts:
Directory: /u01/app/fs1/FMW_Home/webtier/perl/bin/perl -I /u01/app/fs1/FMW_Home/webtier/perl/lib/5.10.0 -I /u01/app/fs1/FMW_Home/webtier/perl/lib/site_perl/5.10.0 -I /u01/app/fs1/EBSapps/appl/au/12.0.0/perl -I /u01/app/fs1/FMW_Home/webtier/ohs/mod_perl/lib/site_perl/5.10.0/x86_64-linux-thread-multi /u01/app/fs1/inst/apps/ACE_samarthapps/admin/install
txkGenADOPWrapper.pl INSTE8_APPLY 1
AutoConfig is exiting with status 2
The following error can also be found in RCloneApplyAppstier_xxxx.log file:
STACK TRACE
at …fs2/EBSapps/appl/au/12.0.0/perl/TXK/Error.pm line 168
TXK::Error::abort(‘TXK::Error’, ‘HASH(0x1e1aaa8)’) called at …fs2/EBSapps/appl/au/12.0.0/perl/TXK/Common.pm line 299
TXK::Common::doError(‘TXK::SQLPLUS=HASH(0x2581090)’, ‘SQLPLUS error: buffer=\x{a}\x{a}SQL*Plus: Release 10.1.0.5.0 – Produc…’, undef) called at …fs2/EBSapps/appl/au/12.0.0/perl/TXK/Common.pm line 314
TXK::Common::setError(‘TXK::SQLPLUS=HASH(0x2581090)’, ‘SQLPLUS error: buffer=\x{a}\x{a}SQL*Plus: Release 10.1.0.5.0 – Produc…’) called at …fs2/EBSapps/appl/au/12.0.0/perl/TXK/SQLPLUS.pm line 832
TXK::SQLPLUS::_doExecute(‘TXK::SQLPLUS=HASH(0x2581090)’, 0) called at …fs2/EBSapps/appl/au/12.0.0/perl/TXK/SQLPLUS.pm line 234
TXK::SQLPLUS::execute(‘TXK::SQLPLUS=HASH(0x2581090)’, ‘HASH(0x2e0b910)’) called at …fs2/EBSapps/appl/au/12.0.0/perl/TXK/TechstackDB.pm line 618
TXK::TechstackDB::_getSQLValue(‘TXK::TechstackDB=HASH(0x2571088)’, ‘SELECT ad_zd_adop.get_node_type(\’ebs\’) FROM DUAL’) called at …fs2/EBSapps/appl/au/12.0.0/perl/TXK/TechstackDB.pm line 573
TXK::TechstackDB::getSQLValue(‘TXK::TechstackDB=HASH(0x2571088)’, ‘SELECT ad_zd_adop.get_node_type(\’ebs\’) FROM DUAL’) called at …fs2/inst/apps/EBSDEV_ebs/admin/install/txkGenADOPWrapper.pl line 503
main::getNodeType() called at …fs2/inst/apps/EBSDEV_ebs/admin/install/txkGenADOPWrapper.pl line 199
eval {…} called at …fs2/inst/apps/EBSDEV_ebs/admin/install/txkGenADOPWrapper.pl line 140
)
ERRORCODE = 1 ERRORCODE_END
.end std out.
CHANGES
This error has been found to occur for the following two scenarios:
When the node is migrated the application tier to single target node by following the note Application Tier Platform Migration with Oracle E-Business Suite Release 12.2 (Doc ID 2048954.1)
When cloning from multinode environment
CAUSE
The value of one of the following two variables in the fnd_oam_context_files table is set to ‘disabled’. The function ad_zd_adop.get_node_type() expects the values of BOTH of them to show with the value of ‘enabled’.
– s_web_admin_status
– s_adminserverstatus
The reason of the table fnd_oam_context_files to have these incorrect values is that the same incorrect values exist in the application context file from where the values in the database are updated.
Please be aware that only one of the two variables could have the value ‘disabled’ and the issue would still occur.
SOLUTION:-
To solve this issue modify the application context file with the proper values for s_web_admin_status and s_nodemanagerstatus and then run autoconfig to recreate the fnd_oam_context_files with the new values from the context file. Please do the following:
1. Modify these two variables to ‘enabled’ in the RUN file system context file on the target server.
<oa_service_status oa_var=”s_adminserverstatus”>disabled</oa_service_status>
<oa_service_group_status oa_var=”s_web_admin_status”>disabled</oa_service_group_status>
to
<oa_service_status oa_var=”s_adminserverstatus”>enabled</oa_service_status>
<oa_service_group_status oa_var=”s_web_admin_status”>enabled</oa_service_group_status>
2. Run autoconfig again.
$ sh $AD_TOP/bin/adconfig.sh contextfile=<RUN_CONTEXT_FILE>
3. Run the following function passing the proper node name (e.g. ebs) and this time it should not fail.
SQL> SELECT ad_zd_adop.get_node_type(‘ebs’) FROM DUAL;
Note: the value ‘ebs’ is just an example. You will need to replace it with the value of your target node.
4. Run the script that was failing and now it should be able to pass this error.
