How to fix line 143 ERRORCODE = 1 ERRORCODE_END

In this article, we will see how to fix line 143 ERRORCODE = 1 ERRORCODE_END. Basically, this is autoconfig error, facing while executing in our EBS environment.

While executing autoconfig in appsTier below errors are showing. Here we will try to resolve the reported issue.

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>


  AutoConfig could not successfully instantiate the following files:

    Directory: /oracle/EBSFS

      EBSapps.env             INSTE8


  AutoConfig could not successfully execute the following scripts:

Directory: /oracle/EBSFS/fs1/FMW_Home/webtier/perl/bin/perl -I /oracle/EBSFS/fs1/FMW_Home/webtier/perl/lib/5.10.0 -I /oracle/EBSFS/fs1/FMW_Home/webtier/perl/lib/site_perl/5.10.0 -I /oracle/EBSFS/fs1/EBSapps/appl/au/12.0.0/perl -I /oracle/EBSFS/fs1/FMW_Home/webtier/ohs/mod_perl/lib/site_perl/5.10.0/x86_64-linux-thread-multi /oracle/EBSFS/fs1/inst/apps/ACE_samarthapps/admin/install    INSTE8_APPLY       1

AutoConfig is exiting with status 2

The following error( line 143) can also be found in RCloneApplyAppstier_xxxx.log file:

at ...fs2/EBSapps/appl/au/12.0.0/perl/TXK/ line 168
TXK::Error::abort('TXK::Error', 'HASH(0x1e1aaa8)') called at ...fs2/EBSapps/appl/au/12.0.0/perl/TXK/ line 299
TXK::Common::doError('TXK::SQLPLUS=HASH(0x2581090)', 'SQLPLUS error: buffer=x{a}x{a}SQL*Plus: Release - Produc...', undef) called at ...fs2/EBSapps/appl/au/12.0.0/perl/TXK/ line 314
TXK::Common::setError('TXK::SQLPLUS=HASH(0x2581090)', 'SQLPLUS error: buffer=x{a}x{a}SQL*Plus: Release - Produc...') called at ...fs2/EBSapps/appl/au/12.0.0/perl/TXK/ line 832
TXK::SQLPLUS::_doExecute('TXK::SQLPLUS=HASH(0x2581090)', 0) called at ...fs2/EBSapps/appl/au/12.0.0/perl/TXK/ line 234
TXK::SQLPLUS::execute('TXK::SQLPLUS=HASH(0x2581090)', 'HASH(0x2e0b910)') called at ...fs2/EBSapps/appl/au/12.0.0/perl/TXK/ 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/ 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/ line 503
main::getNodeType() called at ...fs2/inst/apps/EBSDEV_ebs/admin/install/ line 199
eval {...} called at ...fs2/inst/apps/EBSDEV_ebs/admin/install/ line 140
.end std out.


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.


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.


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>


<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/ 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.

If this article helpful to resolve your issue or improve you knowledge, click here to read another article.

For similar issue you may have check another same article, click here.

Leave a Comment