Thursday, July 29, 2010

Forms User Sessions Link Hangs When Using It Through Application Server Control (ASC)


Symptoms

1. Bring up Application Server Control.
2. Click on the Forms link.
3. Click on the User Sessions link.
4.  All that is seen is a an hour glass and no page appears. What should be seen is a page showing information about active forms sessions.  Information such as Process ID, CPU Usage,  Memory Usage, IP Address, etc.
5.  The following tests help identify the problem area:

Test 1

1. Ensure that em_mode is set to one (1) in the formsweb.cfg
2. Run a couple of instances of the test form -> http://machine.domain:port/forms/frmservlet
and ensure the test form comes up.
3. Go to your MIDDLE_TIER_HOME\sysman\admin\scripts and make a backup copy of this file:
formsproc.pl
4. Now, rename ..\formsproc.pl to something else, say formsproc.pl.org
5. Now click on the 'User Session' link and note if you see any different behavior.

Note: What you should normally see is the 'User Session' page that shows Process ID, CPU Usage,
IP  Address, etc but you would not see any session data because formsproc.pl is what provides the
session info data to the page.

6. Rename formsproc.pl.org to it's original name -> formsproc.pl

Test 2. 

This test is to determine if a perl script can be run on your machine as this is needed to
gather the forms 'User Session' data.

1. Ensure you have accomplished steps 1 & 2 from Test 1.
2. Open a command prompt on the middle_tier machine.
3. Set the oracle home. For example, if the middle tier home is 'D:\mid_1012' then issue this
command:

set oracle_home=d:\mid_1012

4. Issue the following command to move to the perl directory:

cd %oracle_home%\perl\5.6.1\bin\MSWin32-x86

6. Now issue this command and note the results: (this is the script that ASC calls to
show forms data)

perl %ORACLE_HOME%\sysman\admin\scripts\formsproc.pl %ORACLE_HOME%\sysman\admin\scripts %ORACLE_HOME%

After a few seconds, depress the 'Enter' key and you may see the message ->

'The system cannot find the path specified'

However, after a few seconds Forms session info should scroll on the screen. If it doesn't you may get an error like the following ->

"cannot connect to Interix subsystem"  (This is an indication of the problem)
Cause
In this case the installation/configuration of the UNIX Interix subsystem is preventing the necessary Forms perl script (formsproc.pl) from running.
Solution

Assuming that the error message "cannot connect to Interix subsystem"  occurred when running Test 2 then de-install the UNIX Interix subsystem.

If an error message related to a different 3rd part software product occurred in Test 2 then de-install it.

Monday, July 5, 2010

How the TNSNAMES.ORA file is used

Here is to explain the behavior how tnsnames.ora and sqlnet.ora file work together. 


1. The default domain in the Sqlnet file is used for a default purpose only. 

CASE 1: 
in tnsnames.ora 
des6i.world = (....)  

in sqlnet.ora file 
names.default_domain = world 

So, in sqlplus log screen, the following can be typed in: scott/tiger@des6i 
Note the fully qualified des6iworld would not be typed in, because it  
will be automatically appended to the end of the connect string specified. 

CASE 2: 
in tnsnames.ora 
des6i.world = (....)  
CASE.NW.NOS.ORALCE.COM = (....) 

in sqlnet.ora file 
names.default_domain = world 

What would happen in the case where multiple domain have been defined in the  
tnsnames.ora but with only one sqlnet.ora?  Just remember, the key is what is  
defined in the TNSNAMES.ORA file, sqlnet.ora is for convenience.   
The entire connect string can be typed in. 

In sqlplus log screen, just type in :  
scott/tiger@des6i  <--- should again work 
scott/tiger@des6i.world  <--- should again work 
scott/tiger@CASE  <--- should *NOT* work, because in fact it will be CASE.world 
scott/tiger@CASE.NW.NOS.ORALCE.COM    <--- should work 

What is being said is that if the domain is added after the name when loginning 
as defined in the tnsnames.ora file, then don't use the default domain that is  
defined in the sqlnet.ora file. 

CASE 3: 
In fact a sqlnet.ora file is not really needed for the purposes of login 

E.g., in tnsnames.ora 
des6i  = (....)   <--- note here, no domain 
CASE.NW.NOS.BOEING.COM = (....) 

no sqlnet.ora file exists anywhere. 

In sqlplus log screen, just type in :  
scott/tiger@des6i  <--- should again work 
scott/tiger@CASE.NW.NOS.BOEING.COM    <--- should work 
scott/tiger@CASE   <--- should *NOT* work 
scott/tiger@des6i.world  <--- should *NOT* work 


Source : Oracle Metalink Note:201316.1