Troubleshooting Oracle EBS R12.1 txkCfgUtlfileDir.pl: APPS Lockouts, Missing AppsUtil JRE & UTL_FILE_DIR Synchronization

Alhamdulillah.

Introduction

While working on an Oracle E-Business Suite R12.1 environment running on Oracle Database 19c, I encountered a failure while configuring the database-side UTL_FILE_DIR replacement using txkCfgUtlfileDir.pl.

The script repeatedly reported:

ERRORMSG: Invalid APPS database user credentials.
ERRORCODE = 1 ERRORCODE_END

At first glance, this looked like a straightforward APPS password problem.

It wasn’t.

The investigation eventually uncovered two separate contributing factors:

Issue 1: The APPS account was being locked by repeated authentication attempts from an external application.
Issue 2: The TXK utility expected a JRE component that was missing from the AppsUtil directory structure.

These were independent issues discovered during different phases of the troubleshooting investigation. After resolving the APPS lockout and verifying the JRE availability, the UTL_FILE_DIR synchronization proceeded to completion: directory objects → setUtlFileDir → syncUtlFileDir → FND_CONC_CLONE.SETUP_CLEAN → Database AutoConfig.

This post documents the investigation and the commands used.

1. Environment

The database environment was:

Oracle E-Business Suite R12.1
Oracle Database 19c
Database CDB : SRCDB
PDB          : TESTDB
Listener     : 1522
Service      : ebs_service

The ORACLE_HOME was:

ORACLE_HOME=$ORACLE_BASE/TESTDB/db/tech_st/19.3.0.0

The EBS database context file was:

CONTEXT_FILE=$ORACLE_HOME/appsutil/TESTDB_dbctx.xml

The environment was loaded with:

cd $ORACLE_HOME
. ./TESTDB_dbctx.env

Validation:

echo "ORACLE_SID=$ORACLE_SID"
echo "ORACLE_HOME=$ORACLE_HOME"
echo "TNS_ADMIN=$TNS_ADMIN"
echo "CONTEXT_FILE=$CONTEXT_FILE"

Expected values:

ORACLE_SID=TESTDB
ORACLE_HOME=$ORACLE_BASE/TESTDB/db/tech_st/19.3.0.0
TNS_ADMIN=$ORACLE_HOME/network/admin/TESTDB_dbctx
CONTEXT_FILE=$ORACLE_HOME/appsutil/TESTDB_dbctx.xml

2. Initial txkCfgUtlfileDir.pl Failure

The initial command was:

perl $ORACLE_HOME/appsutil/bin/txkCfgUtlfileDir.pl \
-contextfile=$CONTEXT_FILE \
-oraclehome=$ORACLE_HOME \
-outdir=$ORACLE_HOME/appsutil/log \
-mode=getUtlFileDir

The script failed with:

FUNCTION: main::validateAppsSchemaCredentials
ERRORMSG: Invalid APPS database user credentials.
ERRORCODE = 1 ERRORCODE_END

The context file itself was found successfully:

Context file:
$ORACLE_HOME/appsutil/TESTDB_dbctx.xml exists.

So the failure was occurring during APPS credential validation.

3. Validate the PDB

Because this was a multitenant database, I first verified the PDB state.

SHOW PDBS;

Output:

CON_ID CON_NAME    OPEN MODE   RESTRICTED
------ ----------- ----------- ----------
2      PDB$SEED    READ ONLY   NO
3      TESTDB      READ WRITE  NO

Then:

ALTER SESSION SET CONTAINER=TESTDB;

The PDB was open read/write, so the next step was to validate the APPS account.

4. APPS Account Investigation

Initially, the APPS account showed as open after an unlock:

ALTER USER APPS ACCOUNT UNLOCK;

Verification:

SELECT username,
       account_status,
       lock_date
FROM dba_users
WHERE username = 'APPS';

At one point:

APPS    OPEN

However, the TXK utility continued to report invalid APPS credentials.

The most useful clue came from the TXK-generated diagnostic log:

cat $ORACLE_HOME/appsutil/log/TXK_UTIL_DIR_*/validate_apps_password.log

The log showed:

Connected to an idle instance.
ERROR:
ORA-28000: The account is locked.

This was much more specific than the generic TXK error. The failure was occurring at the database authentication layer, not at the password validation level.

5. Understanding the TXK Workflow

Rather than treating the generic TXK error at face value, I inspected txkCfgUtlfileDir.pl to understand how the utility validates the APPS credentials.

The script constructs the database connection using the APPS credentials from the EBS configuration and performs the validation through SQL*Plus. The detailed validate_apps_password.log showed ORA-28000, confirming that the failure was occurring at the database authentication layer.

6. Verify Context Configuration

The context file contained:

grep -n -iE 's_apps_user|s_dbSid|s_tools_twotask|s_dbService' \
$CONTEXT_FILE

Relevant values:

s_dbSid       = TESTDB
s_dbService   = ebs_service
s_apps_user   = apps

The database SID, service and listener port were also checked in the context configuration:

grep -n -iE 's_dbSid|s_dbService|s_dbport' \
$CONTEXT_FILE

Result:

s_dbSid       = TESTDB
s_dbService   = ebs_service
s_dbport      = 1522

These values were consistent with the environment.

7. Verify TNS Connectivity

The EBS TNS entry was properly configured for the PDB service.

export TNS_ADMIN=$ORACLE_HOME/network/admin/TESTDB_dbctx

Then:

tnsping TESTDB

Result:

Used TNSNAMES adapter to resolve the alias
Attempting to contact ...
OK (0 msec)

Therefore: TNS resolution and listener connectivity were not the problem.

8. Important Discovery: APPS Account Was Being Locked

At another point during testing, the account showed:

USERNAME        ACCOUNT_STATUS
--------------- -------------------------
APPS            LOCKED(TIMED)

The account was unlocked:

ALTER USER APPS ACCOUNT UNLOCK;

Then a direct connection succeeded:

sqlplus apps@TESTDB

SHOW USER;
USER is "APPS"

This confirmed that the APPS credentials being used for the direct SQL*Plus connection were valid at that point. However, subsequent attempts to run the TXK utility showed the account locked again:

ORA-28000: The account is locked.

This pattern indicated that something was repeatedly attempting authentication with invalid credentials, causing the account to lock after a number of failed attempts. The generic TXK error message “Invalid APPS database user credentials” did not hint at this root cause.

9. SplashBI Was Contributing to the Lockout

During the investigation, SplashBI sessions were identified as contributing to repeated APPS authentication attempts, and stale credentials were suspected.

Those sessions were stopped/killed before continuing with the TXK procedure.

This was a critical troubleshooting lesson:

Do not repeatedly unlock APPS and rerun the TXK utility while another application is continuously attempting to authenticate with stale APPS credentials.

Doing so simply creates another lockout cycle. After the interfering sessions were stopped, APPS authentication could be validated successfully, and the TXK procedure proceeded.

10. A Second Prerequisite Issue: Missing AppsUtil JRE

This was a separate issue discovered during the later stages of the TXK workflow. An earlier execution of syncUtlFileDir had shown:

FUNCTION: main::getJavaCmd

ERRORMSG:
Invalid JDK TOP:
$ORACLE_HOME/appsutil/jre/bin/java

I checked:

ls -ld $ORACLE_HOME/appsutil/jre

and found:

No such file or directory

However, the AppsUtil clone area contained a valid JRE:

ls -ld $ORACLE_HOME/appsutil/clone/jre

and:

ls -l $ORACLE_HOME/appsutil/clone/jre/bin/java

The Java executable was present. Validation:

$ORACLE_HOME/appsutil/clone/jre/bin/java -version

java version "1.8.0_451"
Java(TM) SE Runtime Environment

11. Backup Before Correcting AppsUtil

Before making the AppsUtil change, a backup was taken:

cd $ORACLE_HOME/appsutil

tar -czf $ORACLE_BASE/TESTDB/appsutil_pre_jre_fix_$(date +%Y%m%d_%H%M%S).tar.gz \
    TESTDB_dbctx.xml \
    txkSetCfgCDB.env \
    clone/jre

The backup was verified:

ls -lh $ORACLE_BASE/TESTDB/appsutil_pre_jre_fix_*.tar.gz

-rw-r--r-- 1 oracle dba 46M Aug 18 11:32 appsutil_pre_jre_fix_20260818_113218.tar.gz

This provided a rollback point before modifying the directory structure.

12. Restore the Expected AppsUtil JRE

The TXK source explicitly showed that getJavaCmd expected:

$ORACLE_HOME/appsutil/jre/bin/java

The existing valid JRE under clone/jre was copied to the expected location:

cp -pR $ORACLE_HOME/appsutil/clone/jre \
       $ORACLE_HOME/appsutil/jre

Validation:

ls -ld $ORACLE_HOME/appsutil/jre
ls -l $ORACLE_HOME/appsutil/jre/bin/java

$ORACLE_HOME/appsutil/jre/bin/java -version
java version "1.8.0_451"

This restored the Java path expected by the TXK utility.

13. Existing UTL_FILE_DIR Configuration

An earlier execution had already generated:

$ORACLE_HOME/dbs/TESTDB_utlfiledir.txt

The original getUtlFileDir execution had failed during APPS credential validation when the account was locked. After resolving the APPS lockout and stopping the interfering authentication attempts, the TXK workflow was able to proceed. The existing configuration file from the previous successful run was available as a reference for the required filesystem paths.

The paths included:

$ORACLE_BASE/TESTDB/temp
$APP_MOUNT/TESTDB/inst/apps/TESTDB_dbctx/appltmp
$APP_MOUNT/TESTDB/apps/apps_st/comn/temp
$ORACLE_BASE/TESTDB/db/tech_st/19.3.0.0/admin/po_terms
$ORACLE_BASE/TESTDB/db/tech_st/temp/TESTDB

14. Create the Directory Objects

The TXK utility was then run in createDirObject mode for each required OS path.

perl $ORACLE_HOME/appsutil/bin/txkCfgUtlfileDir.pl \
-contextfile=$CONTEXT_FILE \
-oraclehome=$ORACLE_HOME \
-outdir=$ORACLE_HOME/appsutil/log \
-mode=createDirObject

The utility prompted for:

Enter the APPS Password:
Enter the SYSTEM Password:
Enter the OS path for which directory object needs to be created:

Each of the required paths completed with:

Successfully Completed the script
ERRORCODE = 0 ERRORCODE_END

15. Run setUtlFileDir

The next step was:

perl $ORACLE_HOME/appsutil/bin/txkCfgUtlfileDir.pl \
-contextfile=$CONTEXT_FILE \
-oraclehome=$ORACLE_HOME \
-outdir=$ORACLE_HOME/appsutil/log \
-mode=setUtlFileDir

The script returned:

WARNING: Incorrect value s_applptmp detected on Apps Tier nodes.

However:

Successfully Completed the script
ERRORCODE = 0 ERRORCODE_END

Therefore the operation itself succeeded, while the s_applptmp issue was recorded as a warning for further review.

16. Synchronize UTL_FILE_DIR

The next documented step was:

perl $ORACLE_HOME/appsutil/bin/txkCfgUtlfileDir.pl \
-contextfile=$CONTEXT_FILE \
-oraclehome=$ORACLE_HOME \
-outdir=$ORACLE_HOME/appsutil/log \
-mode=syncUtlFileDir \
-skipautoconfig=yes

This completed successfully:

Successfully Completed the script
ERRORCODE = 0 ERRORCODE_END

At this point the TXK UTL_FILE_DIR synchronization portion was complete.

17. Clean EBS Node Configuration

The next database-side EBS step was:

EXEC FND_CONC_CLONE.SETUP_CLEAN;

COMMIT;

Output:

PL/SQL procedure successfully completed.

Commit complete.

Immediately afterward, querying FND_NODES returned:

no rows selected

This was expected at this point because SETUP_CLEAN removes the existing node registrations so that AutoConfig can rebuild them.

18. Run Database AutoConfig

Database AutoConfig was then executed from the database context directory:

cd $ORACLE_HOME/appsutil
sh adautocfg.sh

The script prompted:

Enter the APPS user password:

The AutoConfig log was located at:

$ORACLE_HOME/appsutil/log/TESTDB_dbctx/[timestamp]/adconfig.log

The important output was:

Context Value Management will now update the Context file

Updating Context file...COMPLETED

Attempting upload of Context file and templates to database...COMPLETED

Updating rdbms version in Context file to db19
Updating rdbms type in Context file to 64 bits

Configuring templates from ORACLE_HOME ...

AutoConfig completed successfully.

This confirmed that the database AutoConfig completed successfully.

19. Validate EBS Node Registration

After AutoConfig completed successfully, the final validation was to confirm that the EBS node registrations had been recreated.

SET LINES 200
SET PAGES 50

COLUMN node_name FORMAT A15
COLUMN host_name FORMAT A30
COLUMN status FORMAT A10
COLUMN cp FORMAT A5
COLUMN forms FORMAT A5
COLUMN web FORMAT A5
COLUMN admin FORMAT A5
COLUMN db FORMAT A5
COLUMN webhost FORMAT A30
COLUMN last_update FORMAT A20

ALTER SESSION SET NLS_DATE_FORMAT='DD-MON-YYYY HH24:MI:SS';

SELECT node_name,
       host || '.' || domain host_name,
       DECODE(status,'Y','active','inactive') status,
       DECODE(support_cp,'Y','yes','no') cp,
       DECODE(support_forms,'Y','yes','no') forms,
       DECODE(support_web,'Y','yes','no') web,
       DECODE(support_admin,'Y','yes','no') admin,
       DECODE(support_db,'Y','yes','no') db,
       webhost,
       last_update_date
FROM apps.fnd_nodes
WHERE node_name != 'AUTHENTICATION'
ORDER BY 7,1;

Output:

NODE_NAME       HOST_NAME                      STATUS     CP    FORMS WEB   ADMIN DB    WEBHOST                   LAST_UPDATE_DATE
--------------- ------------------------------ ---------- ----- ----- ----- ----- ----- ------------------------- --------------------
EBSNODE         [masked-hostname]              inactive   no    no    no    no    yes                           18-AUG-2026 12:50:45

The node registration was successfully rebuilt with the database tier configuration active (DB = yes) and other tiers set to inactive pending app-tier AutoConfig execution.

Root Cause: Two Independent Issues

The investigation identified two distinct, independent issues that required separate solutions. This is important to understand because confusing the two would have masked the actual root cause in each case.

Issue 1 — APPS Account Lockout (Database Authentication Layer)

The TXK utility reported:

Invalid APPS database user credentials.

The detailed validation log showed:

ORA-28000: The account is locked.

The APPS account was repeatedly becoming LOCKED(TIMED) due to repeated authentication attempts. SplashBI sessions were identified as contributing to those attempts. This was resolved by stopping the interfering sessions and unlocking the APPS account.

Issue 2 — Missing AppsUtil JRE (Environment/Configuration Layer)

During the later TXK workflow, syncUtlFileDir encountered:

Invalid JDK TOP:
$ORACLE_HOME/appsutil/jre/bin/java

The expected JRE path did not exist, while a valid JRE was available under:

$ORACLE_HOME/appsutil/clone/jre

This was resolved by copying the JRE to the expected AppsUtil location after taking a backup. This issue was completely independent of the APPS account lockout and would have persisted even if APPS had been unlocked from the start.

Key lesson: Do not conflate unrelated failures during troubleshooting. Each issue required its own diagnosis and its own fix. Resolving one would not have solved the other.

Troubleshooting Sequence

Phase 1: APPS/TXK Troubleshooting

Validate CDB/PDB state
Validate EBS context configuration
Validate TNS connectivity
Check APPS account status
Inspect validate_apps_password.log
Identify repeated APPS authentication attempts
Stop interfering SplashBI sessions
Unlock APPS
Validate direct APPS login

Phase 2: TXK/UTL_FILE_DIR Configuration

Verify AppsUtil JRE
Take AppsUtil backup
Restore expected appsutil/jre if required
Create directory objects
setUtlFileDir
syncUtlFileDir -skipautoconfig=yes
FND_CONC_CLONE.SETUP_CLEAN
COMMIT
Run Database AutoConfig
Validate FND_NODES
Perform final verification

Troubleshooting Lessons

1. Don’t trust the top-level TXK error blindly

This:

Invalid APPS database user credentials

does not necessarily mean the APPS password is wrong.

Always inspect:

validate_apps_password.log

In this case it exposed:

ORA-28000: The account is locked.

2. Check for external applications causing APPS lockouts

If APPS repeatedly becomes:

LOCKED(TIMED)

don’t continuously unlock it and retry.

Look for applications such as:

SplashBI
integrations
monitoring tools
application servers
scheduled jobs

that may still have stale APPS credentials.

3. In a CDB/PDB environment, verify the complete connection path

Validate:

CDB
PDB
SERVICE_NAME
TNS alias
PORT
APPS account

For example:

tnsping TESTDB
sqlplus apps@TESTDB

4. Inspect the TXK source when the error is unclear

The getJavaCmd function made the missing JRE requirement explicit in the source code. This was much more useful than simply treating the Invalid JDK TOP error as a generic Java problem.

5. Take a backup before modifying AppsUtil

The backup provided a simple rollback point:

tar -czf $ORACLE_BASE/TESTDB/appsutil_pre_jre_fix_$(date +%Y%m%d_%H%M%S).tar.gz \
    TESTDB_dbctx.xml \
    txkSetCfgCDB.env \
    clone/jre

Final Validation

With AutoConfig completed successfully, the final validations confirmed that the database-side configuration was healthy and that the EBS node registration had been rebuilt:

FND_NODES query returned the EBSNODE with DB support active
APPS login successful
AutoConfig completed with no errors
txkCfgUtlfileDir.pl returned ERRORCODE = 0 for all modes
UTL_FILE_DIR directory objects successfully created

The database-tier configuration was now ready for app-tier AutoConfig to follow, which would complete the clone or refresh procedure.

Closing

This issue initially looked like a simple APPS authentication problem. The actual troubleshooting required following the failure through several layers: APPS account state → PDB/service connectivity → authentication log inspection → identification of external authentication interference → TXK environment validation → prerequisite verification → directory object creation → EBS node cleanup → AutoConfig.

The key was to validate each layer independently and avoid assuming causality between separate findings. The APPS lockout issue and the missing JRE issue were distinct problems requiring distinct solutions.

ما شاء الله

Troubleshooting Oracle EBS R12.1 txkCfgUtlfileDir.pl: APPS Lockouts, Missing AppsUtil JRE & UTL_FILE_DIR Synchronization

Introduction

1. Environment

2. Initial txkCfgUtlfileDir.pl Failure

3. Validate the PDB

4. APPS Account Investigation

5. Understanding the TXK Workflow

6. Verify Context Configuration

7. Verify TNS Connectivity

8. Important Discovery: APPS Account Was Being Locked

9. SplashBI Was Contributing to the Lockout

10. A Second Prerequisite Issue: Missing AppsUtil JRE

11. Backup Before Correcting AppsUtil

12. Restore the Expected AppsUtil JRE

13. Existing UTL_FILE_DIR Configuration

14. Create the Directory Objects

15. Run setUtlFileDir

16. Synchronize UTL_FILE_DIR

17. Clean EBS Node Configuration

18. Run Database AutoConfig

19. Validate EBS Node Registration

Root Cause: Two Independent Issues

Issue 1 — APPS Account Lockout (Database Authentication Layer)

Issue 2 — Missing AppsUtil JRE (Environment/Configuration Layer)

Troubleshooting Sequence

Phase 1: APPS/TXK Troubleshooting

Phase 2: TXK/UTL_FILE_DIR Configuration

Troubleshooting Lessons

1. Don’t trust the top-level TXK error blindly

2. Check for external applications causing APPS lockouts

3. In a CDB/PDB environment, verify the complete connection path

4. Inspect the TXK source when the error is unclear

5. Take a backup before modifying AppsUtil

Final Validation

Closing

Share this:

Discover more from Syed Anwar Ahmed – Oracle DBA Blog

Comments

Leave a comment Cancel reply

More posts

Oracle EBS WebLogic: Troubleshooting Security:090220 Rule 2 Connection Rejection

Troubleshooting Oracle EBS R12.1 txkCfgUtlfileDir.pl: APPS Lockouts, Missing AppsUtil JRE & UTL_FILE_DIR Synchronization

When OPMN Enters a Restart Loop: Troubleshooting Oracle EBS OC4J Instability on AIX

Oracle EBS R12.2 Multi-Node Patching in Downtime Mode: Recovering a Failed Slave Node with restart=yes

Discover more from Syed Anwar Ahmed – Oracle DBA Blog