FRM-92050: Failed to connect to the Server: kiranginni.working.com:10013

After R12 CPU Patching facing this problem. Main issue is due to permissions. But issue is deviating.

Forms Error frm front end:-
==========================
FRM-92050: Failed to connect to the Server: kiranginni.working.com:10013
[AMD64] apkiran@ginni06 > adformsrvctl.sh status
You are running adformsrvctl.sh  version 120.9.12000000.9
Checking status of FORMS Server (Socket Mode) ...
Forms Server (Socket) is not running
adformsrvctl.sh: exiting with status 0
adformsrvctl.sh: check the logfile /kiran/mtlog/KIRAN_ginni06/logs/ora/10.1.2/forms/socket.log for more
information ... 

AMD64] apkiran@ginni06 > adformsrvctl.sh start
You are running adformsrvctl.sh  version 120.9.12000000.9
Starting FORMS Server in Socket Mode...
Calling txkChkFormsDeployment.pl to check whether latest FORMSAPP.EAR is deployed...
*** ALL THE FOLLOWING FILES ARE REQUIRED FOR RESOLVING RUNTIME ERRORS
*** Log File =
/kiran/mtlog/KIRAN_ginni06/logs/appl/rgf/TXK/txkChkFormsDeployment_Sat_Nov_20_06_52_04_2010/txkChkForms
Deployment_Sat_Nov_20_06_52_04_2010.log
Program : /kiran/applmgr/1200/fnd/12.0.0/patch/115/bin/txkChkFormsDeployment.pl started @ Sat Nov 20

06:52:05 2010
*** Log File =
/kiran/mtlog/KIRAN_ginni06/logs/appl/rgf/TXK/txkChkFormsDeployment_Sat_Nov_20_06_52_04_2010/txkChkForms
Deployment_Sat_Nov_20_06_52_04_2010.log

Program : /kiran/applmgr/1200/fnd/12.0.0/patch/115/bin/txkChkFormsDeployment.pl completed @ Sat Nov 20
06:52:05 2010

Error while executing the perl script txkChkFormsDeployment.pl
/kiran/mtlog/KIRAN_ginni06/logs/ora/10.1.2/forms/socket.log
adformsrvctl.sh: exiting with status 1
[AMD64] apkiran@ginni06 >


From the log file :
/kiran/mtlog/KIRAN_ginni06/logs/appl/rgf/TXK/txkChkFormsDeployment_Sat_Nov_20_06_52_04_2010/txkChkForms
Deployment_Sat_Nov_20_06_52_04_2010.log
MESSAGES:
Unable to create /kiran/applcsf/tmp/TXK
Cannot confirm access permissions - REASON stack:
*DIR* /kiran/applcsf/tmp/TXK  directory with no write permission
*DIR* /kiran/applcsf/tmp  directory with write permission
*DIR* /kiran/applcsf  directory with write permission
*DIR* /kiran  directory with no write permission
*DIR* /  directory with no write permission

Access permission error on /kiran/applcsf/tmp/TXK
Directory /kiran/applcsf/tmp/TXK not writable

STACK TRACE
TXK::Error::abort('TXK::Error','HASH(0x82152b4)') called at
/kiran/applmgr/1200/au/12.0.0/perl/TXK/Common.pm line 299
TXK::Common::doError('TXK::FileSys=HASH(0x861bc54)','Unable to create

/kiran/applcsf/tmp/TXK','undef') called at /kiran/applmgr/1200/au/12.0.0/perl/TXK/Common.pm line 314
TXK::Common::setError('TXK::FileSys=HASH(0x861bc54)','Unable to create /kiran/applcsf/tmp/TXK')
called at /kiran/applmgr/1200/au/12.0.0/perl/TXK/FileSys.pm line 354
TXK::FileSys::create('TXK::FileSys=HASH(0x861bc54)','HASH(0x88c3828)') called at
/kiran/applmgr/1200/au/12.0.0/perl/TXK/Techstack.pm line 1730
TXK::Techstack::getAppsTempDir('TXK::Techstack=HASH(0x8609dfc)','HASH(0x8619070)') called at

/kiran/applmgr/1200/au/12.0.0/perl/TXK/Techstack.pm line 7243
TXK::Techstack::getTempFileLoc('TXK::Techstack=HASH(0x8609dfc)') called at
/kiran/applmgr/1200/au/12.0.0/perl/TXK/Techstack.pm line 7177
TXK::Techstack::txkFormsDeploymentStatus('TXK::Techstack=HASH(0x8609dfc)') called at
/kiran/applmgr/1200/fnd/12.0.0/patch/115/bin/txkChkFormsDeployment.pl line 225
eval {...} called at /kiran/applmgr/1200/fnd/12.0.0/patch/115/bin/txkChkFormsDeployment.pl line 143
require /kiran/applmgr/1200/fnd/12.0.0/patch/115/bin/txkChkFormsDeployment.pl called at

/kiran/applmgr/1200/au/12.0.0/perl/TXK/RunScript.pm line 105
TXK::RunScript::require
('TXK::RunScript','/kiran/applmgr/1200/fnd/12.0.0/patch/115/bin/txkChkFormsDepl...') called at
/kiran/applmgr/1200/au/12.0.0/perl/TXK/Script.pm line 177
eval {...} called at /kiran/applmgr/1200/au/12.0.0/perl/TXK/Script.pm line 177
TXK::Script::run('TXK::Script=HASH
(0x85a0b1c)','/kiran/mtlog/KIRAN_ginni06/logs/appl/rgf/TXK','/kiran/applmgr/1200/fnd/12.0.0/patch/115/
bin/txkChkFormsDepl...') called at /kiran/applmgr/1200/fnd/12.0.0/bin/txkrun.pl line 150
)

[AMD64] apkiran@ginni06 > adformsrvctl.sh start
You are running adformsrvctl.sh  version 120.9.12000000.9
Starting FORMS Server in Socket Mode...
Calling txkChkFormsDeployment.pl to check whether latest FORMSAPP.EAR is deployed...
*** ALL THE FOLLOWING FILES ARE REQUIRED FOR RESOLVING RUNTIME ERRORS
*** Log File =
/kiran/mtlog/KIRAN_ginni06/logs/appl/rgf/TXK/txkChkFormsDeployment_Sat_Nov_20_06_54_46_2010/txkChkForms
Deployment_Sat_Nov_20_06_54_46_2010.log
Program : /kiran/applmgr/1200/fnd/12.0.0/patch/115/bin/txkChkFormsDeployment.pl started @ Sat Nov 20
06:54:47 2010
*** Log File =
/kiran/mtlog/KIRAN_ginni06/logs/appl/rgf/TXK/txkChkFormsDeployment_Sat_Nov_20_06_54_46_2010/txkChkForms
Deployment_Sat_Nov_20_06_54_46_2010.log

=============================================
*** Latest formsapp.ear has been deployed ***
=============================================

Program : /kiran/applmgr/1200/fnd/12.0.0/patch/115/bin/txkChkFormsDeployment.pl completed @ Sat Nov 20
06:54:47 2010
Perl script txkChkFormsDeployment.pl got executed successfully

adformsrvctl.sh: exiting with status 0
adformsrvctl.sh: check the logfile /kiran/mtlog/KIRAN_ginni06/logs/ora/10.1.2/forms/socket.log for more
information ... 
>>>>>>>>>>>>>>>>>> ISSUE Got Resolved >>>>>>>>>>>>>>>>>>>>>>.
Summary:- There is some permission issue where script "adformsrvctl.sh " failed during execution of txkChkFormsDeployment.pl which is trying to use directory "/kiran/applcsf/tmp/TXK" not writable.
Given write permissions & ran failed script >>> issue resolved.
>>>>>>>>>>>>>>>>>> ISSUE Got Resolved >>>>>>>>>>>>>>>>>>>>>>.

APPS Issue: >> FRM-92050 Failed to connect to the server

Forms interface was not launching with this error:
FRM-92050: Failed to connect to the Server: kiranginni.working.com:8000
Details:
Java Exception:
java.io.EOFException
at java.io.DataInputStream.readInt(Unknown Source)
at oracle.forms.net.SocketConnection.connect(Unknown Source)
at oracle.forms.engine.Runform.initConnection(Unknown Source)
at oracle.forms.engine.Runform.startRunform(Unknown Source)
at oracle.forms.engine.Main.createRunform(Unknown Source)
at oracle.forms.engine.Main.start(Unknown Source)
at sun.applet.AppletPanel.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
I tried doing a telnet kiranginni.working.com 8000. This is a good test to see if the service is running. The service was not running. It was started through adfrmctl.sh. When I tried again, it connected but on pressing enter the connection was broken, which should not happen.
I found a direct hit in Metalink Note: 438231.1
Forms Server is up (f60webmx process is shown as a result of "ps -ef | grep f60" command) but when starting the forms server with the following command instead of adfrmctl.sh:
f60srvm em=__QA port= log=forms_log.txt mode=socket exe=f60webmx 2>&1 | tee forms_out.txt &
It returns
Failed to exec runform f60webmx
Cause
The issue is caused by the following setup: $FND_TOP/bin/f60webmx is renamed (e.g. to $FND_TOP/bin/f60webmx.sav) or removed and thus is inaccessible.
A similar issue is described in Metalink Note 1079806.6: Failed to Exec Runform when Starting Forms Server.
To relink f60webmx, I executed:
adrelink.sh force=y ranlib=y "fnd f60webmx"
It errored out with:
make -f $APPL_TOP/admin/out/link_fnd_21892.mk $FND_TOP/bin/f60webmx
Starting link of fnd executable 'f60webmx' on Fri Mar 27 16:02:14 EDT 2009
make: Fatal error: Don't know how to make target `$FND_TOP/lib/xitiap.o'
Done with link of fnd executable 'f60webmx' on Fri Mar 27 16:02:14 EDT 2009
Metalink Note 178919.1 describes this problem and sites missing file as the cause.
When I checked for $FND_TOP/lib/xitiap.o, it was indeed missing.
So I compared the number of files in $FND_TOP/lib in this instance and another instance. Total of 4 files were missing in this instance:
afpwrr.o
fdrrun.o
xitfnd.o
xitiap.o
These 4 files were copied from a working instance, and ran:
adrelink.sh force=y ranlib=y "fnd f60webmx"
f60webmx got created without any errors this time.
FRM-92050 error also disappeared as forms was able to locate f60webmx.

ORACLE ACTIVE DATA GUARD

Stop spending money on disaster recovery (DR) systems that sit idle waiting for a disaster to occur. Stop assuming that complex replication solutions are required to put idle DR systems to work. Stop buying more capacity for read-only workload. Stop wondering if your DR system is really ready to take over the production role when disaster strikes. Start using Active Data Guard to quickly transform your DR system into a reliable, productive asset used to offload read-only workload from your production database.
Oracle Active Data Guard

Active Data Guard provides the management, monitoring, and automation software to create and maintain one or more synchronized replicas (standby databases) of a production database (primary database). An Active Data Guard standby database is an exact copy of the primary that is open read-only while it continuously applies changes transmitted by the primary database. An active standby can offload ad-hoc queries, reporting, and fast incremental backups from the primary database, improving performance and scalability while preventing data loss or downtime due to data corruptions, database and site failures, human error, or natural disaster.
Protection

Active Data Guard is a loosely coupled architecture where standby databases are isolated from failures that can occur at the primary database. Primary database changes are transmitted directly from memory, isolating the standby from I/O corruptions that occur at the primary. The software code-path executed on an active

1 ORACLE DATA SHEET

standby is different from that of the primary – isolating it from firmware and software errors that impact the primary. Oracle corruption-detection checks insure that data is logically and physically consistent before it is applied to a standby database. An active standby also acts as a “canary in a coal mine” by detecting silent corruptions that can occur at the primary due to hardware errors (memory, cpu, disk, NIC) and data transfer faults, preventing them from impacting the standby database.

Availability
Maintaining an independent replica of a mission critical database provides the ultimate level of high availability. In the event of a planned or unplanned outage, an Active Data Guard standby provides high availability by quickly transitioning to the primary role, either manually or automatically, preventing downtime and data loss.

Return on Investment
Active Data Guard puts idle systems to work improving systems utilization. It is incredibly efficient - its replication process uses less computing resource, leaving more capacity for production applications. It is simple to implement and manage, reducing administrative cost and complexity.


Performance
Active Data Guard is the simplest, highest performance solution for maintaining a synchronized independent copy of the Oracle Database. It is the only replication technology able to support the very high volumes driven by the Oracle Database Machine and Oracle Exadata. Oracle 11g Release 2 tests using an Oracle Database Machine proved Active Data Guard was able to apply changes at a sustained rate greater than 500MB/second.


Confidence
Active Data Guard can do what no other data protection technology can do for the Oracle Database. It provides unique levels of simplicity, performance, reliability and the security of having an independent, exact replica of the production database. It eliminates the unknown by being able to validate the production readiness of the standby database by querying it at any time – without impacting data protection or your ability to immediately transition it to the primary role.