Oracle apps:FNDFS working

1) The user selects ‘Request Output’, ‘Request Log’, or ‘Manager Log’

2) The file name and nodename are selected from the database.
Reports:
SELECT outfile_name, outfile_node_name FROM fnd_concurrent_requests
WHERE request_id = :id;
Logfiles:
SELECT logfile_name, logfile_node_name FROM fnd_concurrent_requests
WHERE request_id = :id;
Manager logs:
SELECT logfile_name, node_name FROM fnd_concurrent_processes
WHERE concurrent_process_id = :process_id;


4. The client takes the nodename that was returned and adds FNDFS_ to the
beginning of it. For example, if xprod_ser1 was returned as the node name, the
client would construct the string: FNDFS_xprod_ser1

5. The client takes this string and attempts to use it as a SQL*Net connect
descriptor. SQL*Net will attempt to resolve this descriptor into a host and SID
using a local tnsnames.ora file or Oracle Names.
6. If successfully resolved, a connection is made to the given host. The listener on
this host receives the connection request, and resolves the SID using its
listener.ora file. If it finds a PROGRAM parameter listed for this SID, it will
launch this program. (which should be $FND_TOP/bin/FNDFS)

7. The FNDFS executable runs. The client sends RPC commands to it to return the
requested file.

Common error
An error occurred while attempting to establish an application file server
connection with the node There may be a network connection
problem or the listener on node may not be running.

-This can indicate a multitude of problems, and unfortunately, it does not display anymore helpful messages.

-This most commonly indicates a problem with the local tnsnames.ora file or the
listener.ora file on the server. Check that the customer added an FNDFS entry to the
tnsnames.ora file.

-Check that the hostname and port are correct. Make sure that the entry is named
FNDFS_hostname. Also, if the customer has edited the file himself, he may have
inadvertently corrupted the file. SQL*Net is very picky about the syntax of this file.

-An extra space or carriage return could cause RRA to fail. The only supported
method of editing this file is to use Network Manager. Have the customer backup the
old file, then create a new one with Network Manager if you suspect that this file
may be bad.

-Once you are sure the tnsnames.ora file is correct, you should be able to use TNSPing to ping the listener. (Be sure to ping the FNDFS alias) It should return an OK result.

-Errors here may indicate that the listener is not properly set up.

-Make sure that you are using the exact name of the server (check this with: uname -n) If you have the wrong name in the tnsnames file entry, the tnsping will work, but
RRA will not. For example, suppose the server’s real name is XPROD_SER1, and you
create a tnsnames entry called: FNDFS_DBSERV because you have a DNS alias for
this server. You can ping the server normally, because DNS will resolve this name for
you. You can run TNSPing with FNDFS_DBSERV and it will resolve this connect
string and it will ping the server and return an OK result. This would lead you to
believe that everything is OK on the client side. However, RRA still does not work.
This is because RRA is using the real server name, and it is trying to resolve the
connect string FNDFS_XPROD_SER1, and this entry does not exist. A client-side trace
would discover this error.
----------
Source:-http://appsoracle.blogspot.com/2011/05/oracle-appsfndfs-working.html
----------