Oracle EBS R12.2 Clone Troubleshooting: RC-50221 Port Pool Conflict and FRM-92101 Forms Session Failed During Startup

Disclaimer: This article is based on field experience and publicly shareable troubleshooting steps. Oracle MOS notes are referenced for further reading. Customers with active Oracle Support should review the referenced MOS documents for complete guidance.

Category: Oracle EBS R12.2 | Cloning | Troubleshooting
Level: Intermediate to Advanced
Reference: MOS Doc ID 454427.1

Introduction

Cloning an Oracle E-Business Suite R12.2 application tier is a common activity — whether for setting up a DEV, TEST, or UAT environment. While the process is well-documented, real-world scenarios often throw up issues that aren’t immediately obvious from the error messages alone.

In this post, I walk through two common issues encountered during an EBS R12.2 app tier clone using adcfgclone.pl:

1. RC-50221: Port Pool Not Free — CloneContext failing due to an already-occupied port pool
2. FRM-92101: Forms Session Failed During Startup — Forms not launching due to missing library dependencies or invalid symlinks

Both issues are real, well-known, and worth documenting together since they often appear in sequence during a clone.

---

Environment Details

• Oracle EBS Version: R12.2.x
• OS: Oracle Linux 7 (OL7) / RHEL 7
• Clone type: Application Tier only (adcfgclone.pl appsTier)
• Target server: Fresh clone target (non-production)

---

Issue 1: RC-50221 — Port Pool Not Free

Symptom

When running adcfgclone.pl appsTier, the CloneContext step prompts for a Target System Port Pool and throws the following warning/error:

Checking the port pool 0
RC-50221: Warning: Port Pool 0 is not free.
Please check logfile $COMMON_TOP/clone/bin/CloneContext_<timestamp>.log for conflicts.
RC-00201: Error: Not a valid port pool number
ERROR: Context creation not completed successfully.

CloneContext Log Location

$COMMON_TOP/clone/bin/CloneContext_<timestamp>.log
# Or typically:
/u01/APPLTOP/EBSapps/comn/clone/bin/CloneContext_<timestamp>.log

Root Cause

Port pool 0 is already in use by another EBS instance running on the same server, causing CloneContext validation to fail. Port pool 0 generally corresponds to the initially configured EBS port set for that environment. Actual port assignments vary by release, topology, and previous configuration changes.

ps -ef | grep weblogic | grep AdminServer
lsof -i -P | grep LISTEN | grep <applcrp_user>

Diagnosis

Check which port pools are already in use:

grep -i "port_pool" $CONTEXT_FILE
cat $INST_TOP/admin/out/portpool.lst

You can also use the following utility to validate port availability before proceeding with the clone:

perl $AD_TOP/bin/txkValidateRollupPorts.pl \
-contextfile=$CONTEXT_FILE \
-outfile=/tmp/portcheck.txt

Review /tmp/portcheck.txt for any conflicts before selecting a port pool number.

Fix

Target System Port Pool [0-99] : 1
Checking the port pool 1
done: Port Pool 1 is free

Important Note: Using a different port pool causes Oracle EBS to calculate a different set of ports based on the predefined port pool mapping. The resulting ports are not always a simple increment of one and should be verified in the generated context file after CloneContext completes.

Always verify the actual assigned ports:
grep -i "port" $CONTEXT_FILE | grep -v "#"
cat $INST_TOP/admin/out/portpool.lst

If your firewall rules, load balancer, or application configuration depend on specific port numbers, plan accordingly or stop the existing instance first to free pool 0.

Patch File System Port Pool

For R12.2 dual file system architecture, the Patch file system must use a different port pool than the Run file system. AutoConfig and cloning utilities will calculate a separate set of ports accordingly.

Patch file system should have different port pool than Run file system.
Target System Port Pool [0-99] : 2

---

Issue 2: FRM-92101 — Forms Session Failed During Startup

Symptom

FRM-92101: There was a failure in the Forms Server during startup.
Please look into the web-server log file for details.
Java Exception:
oracle.forms.net.ConnectionException: Forms session <1> failed during startup:
no response from runtime process

What This Means

The WebLogic Forms server (forms_server1) is running, but the underlying Forms runtime process (frmweb) is failing to start. WebLogic receives no response from it, and the session times out. FRM-92101 can have more than one root cause — the key is to run frmweb directly to identify which one applies.

Log Analysis

tail -100 $EBS_DOMAIN_HOME/servers/forms_server1/logs/forms_server1.log

This indicates that the Forms managed server is up and processing requests, shifting the investigation toward the underlying frmweb runtime process.

First Diagnostic Step: Run frmweb Directly

The most effective way to identify the root cause is to source the 10.1.2 environment and run frmweb manually:

. /u01/APPLTOP/EBSapps/10.1.2/EBS_appserver.env
$ORACLE_HOME/bin/frmweb

The output will indicate which root cause applies:

• Undefined symbol errors (e.g. Symbol nnftboot was referenced...not found) → Root Cause 1: Invalid ldflags symlink
• Missing shared library error (e.g. libXm.so.2: cannot open shared object file) → Root Cause 2: Missing OpenMotif symlink

---

Root Cause 1: Invalid ldflags Symlink

Symptom

Running frmweb directly produces undefined symbol errors:

rtld: 0712-001 Symbol nnftboot was referenced from module frmweb(), but a runtime definition of the symbol was not found.
rtld: 0712-001 Symbol ldap_search_s was referenced from module frmweb(), but a runtime definition of the symbol was not found.

Root Cause

Investigation revealed that the ldflags symbolic link under $ORACLE_HOME/lib32 was missing or pointing to an incorrect location, causing the Forms executable to fail during startup. This is a known issue after fresh installations or clones and is referenced in MOS Doc ID 454427.1.

Verify ldflags

ls -la $ORACLE_HOME/lib32/ldflags

If the symlink is missing or pointing to a non-existent path, it needs to be corrected to point to $ORACLE_HOME/lib/ldflags.

Fix

After correcting the ldflags symbolic link and relinking the Forms components, frmweb started successfully. The relinking is performed using the Forms makefile under the 10.1.2 Oracle Home. Refer to MOS Doc ID 454427.1 for the complete steps applicable to your environment.

---

Root Cause 2: Missing OpenMotif Library Symlink

Symptom

Running frmweb directly produces a missing shared library error:

error while loading shared libraries:
libXm.so.2: cannot open shared object file: No such file or directory

Root Cause

The Oracle Forms runtime binary frmweb is compiled against libXm.so.2 (OpenMotif 2.x). On newer Linux versions (OL7/OL8/RHEL7/RHEL8), the installed OpenMotif package provides libXm.so.4, but the compatibility symlink libXm.so.2 → libXm.so.4 is missing.

Verify with ldd

ldd $ORACLE_HOME/bin/frmweb | grep Xm
# Before fix:
libXm.so.2 => not found
# After fix:
libXm.so.2 => /usr/lib/libXm.so.4 (0x...)

Option A: Create the Missing Symlink (Quick Fix)

📌 Note on 32-bit vs 64-bit Libraries: On some Linux platforms the required library may reside under /usr/lib64 rather than /usr/lib. Always verify the actual location before creating symbolic links.

# Step 1: Find the actual location of libXm.so.4
ls -l /usr/lib/libXm.so*
ls -l /usr/lib64/libXm.so*
# Step 2: Create the symlink (run as root)
# If library is in /usr/lib:
ln -s /usr/lib/libXm.so.4 /usr/lib/libXm.so.2
# If library is in /usr/lib64:
ln -s /usr/lib64/libXm.so.4 /usr/lib64/libXm.so.2
# Step 3: Verify
ldd $ORACLE_HOME/bin/frmweb | grep Xm
# Expected: libXm.so.2 => /usr/lib/libXm.so.4 (or /usr/lib64/...)

Option B: Install openmotif21 (Recommended Clean Fix)

# Step 1: Check current state
rpm -qa | grep motif
# Step 2: Enable ol7_addons repo (as root)
yum-config-manager --enable ol7_addons
# Step 3: Remove lesstif if present
yum remove lesstif
# Step 4: Install openmotif21
yum install --setopt=obsoletes=0 openmotif21

Post-Fix: Bounce EBS Services and Validate

cd $ADMIN_SCRIPTS_HOME
./adstpall.sh apps/<apps_password>
./adstrtal.sh apps/<apps_password>
# Or start Forms server specifically:
./admanagedsrvctl.sh start forms_server1

After starting the services, verify that frmweb runtime processes are spawning successfully:

ps -ef | grep frmweb
ps -ef | grep forms

Then launch a Forms-based responsibility or function to confirm successful startup.

---

Conclusion

Both RC-50221 and FRM-92101 are common issues that can delay Oracle EBS R12.2 cloning activities. While the error messages may initially appear unrelated, a structured troubleshooting approach focusing on log analysis, port validation, and runtime dependency checks can quickly identify the root cause and reduce downtime.

---

Summary

Issue	Root Cause	Fix
RC-50221: Port Pool Not Free	Another EBS instance occupying port pool 0	Use port pool 1 (or stop existing instance first)
FRM-92101: ldflags issue	ldflags symlink missing or pointing to wrong location	Fix ldflags symlink and relink Forms components (MOS Doc ID 454427.1)
FRM-92101: OpenMotif issue	libXm.so.2 symlink missing after clone	ln -s /usr/lib[64]/libXm.so.4 /usr/lib[64]/libXm.so.2 or install openmotif21

---

Key Diagnostic Commands Cheat Sheet

# Check which port pools are in use
grep -i "port_pool" $CONTEXT_FILE
cat $INST_TOP/admin/out/portpool.lst
# Validate port availability
perl $AD_TOP/bin/txkValidateRollupPorts.pl -contextfile=$CONTEXT_FILE -outfile=/tmp/portcheck.txt
# Check running WebLogic processes
ps -ef | grep weblogic | grep -v grep
# Run frmweb manually to see actual error
$ORACLE_HOME/bin/frmweb
# Check frmweb library dependencies
ldd $ORACLE_HOME/bin/frmweb | grep Xm
# Check ldflags symlink
ls -la $ORACLE_HOME/lib32/ldflags
# Check OpenMotif installation
rpm -qa | grep motif
# Check Forms runtime processes
ps -ef | grep frmweb
# Check Forms server log
tail -100 $EBS_DOMAIN_HOME/servers/forms_server1/logs/forms_server1.log

---

Lessons Learned

• FRM-92101 is often a symptom, not the root cause. The WebLogic log may show the Java exception, but the actual failure is in the native frmweb binary. Always run frmweb directly to see the real error.
• FRM-92101 has multiple root causes. Check the actual error output from frmweb to distinguish between an ldflags relinking issue and a missing OpenMotif library symlink.
• Use ldd to diagnose missing shared library dependencies. It quickly identifies unresolved libraries without having to dig through multiple log files.
• Verify port pool availability before starting a clone. Stop existing instances or choose a different pool to avoid RC-50221 errors.
• Always validate the resulting ports in the generated context file after CloneContext completes. Port pool mapping is predefined and the assigned ports should be confirmed before proceeding.
• Newer Linux builds may include libXm.so.4 but not the compatibility symlink required by Oracle Forms. OL7/OL8 installations do not always create libXm.so.2 automatically.
• Document port assignments after every clone to avoid firewall and load balancer configuration issues down the line.

---

Keywords

• Oracle EBS R12.2 Clone
• Oracle EBS R12.2 Forms Error
• RC-50221 Port Pool Not Free
• RC-50221 CloneContext Failed
• FRM-92101 Forms Session Failed During Startup
• FRM-92101 No Response From Runtime Process
• ldflags symlink Oracle Forms
• libXm.so.2 not found
• Oracle Forms Runtime Process
• adcfgclone.pl appsTier
• adcfgclone.pl appsTier Error
• Oracle EBS Clone Troubleshooting
• Oracle Linux 7 OpenMotif Issue
• OpenMotif
• frmweb
• CloneContext

---

References

• MOS Doc ID 454427.1 — FRM-92101: There was a failure in the Forms Server during startup
• Oracle EBS R12.2 Cloning Guide

Related Technologies

• Oracle E-Business Suite R12.2
• Oracle Forms
• Oracle WebLogic Server
• Oracle Linux 7
• OpenMotif
• AutoConfig
• Rapid Clone

---

Syed Anwar Ahmed
Oracle ACE Associate | Oracle Apps DBA
Sharing real-world Oracle EBS administration, cloning, patching, and troubleshooting experiences.
Blog: syedanwarahmedoracle.blog