今天在运行请求时候得到如下的错误日志：
原因：由于ORA-20100:为FND_FILE创建文件o0003167.tmp失败。
在请求日志的错误原因中您会找到更详细的信息。
查找了一些资料，总结了一下出问题的原因。
1.查看$APPLPTMP系统环境变量的值，一般是/usr/tmp，需要保证该文件夹是存在的。
2.查看utl_file_dir数据库参数，其第一个值也应该为/usr/tmp;
SELECT * FROM V$PARAMETER V WHERE v.NAME='utl_file_dir'
3.查看该文件夹的权限，该文件夹必须为应用用户和数据库用户都具有读写权限。
4.通过exec FND_FILE.PUT_LINE(FND_FILE.LOG, 'THIS IS A TEST');进行测试，查看是否能输入文件。
我做了上面的四个步骤，发现4能正常运行结束，我为什么请求上会报错呢？最后终于找到了原因，我是一台服务器上面装了两套环境的应用，环境管理员在刻环境的时候，没有修改$APPLPTMP的值，导致两个环境都往/usr/tmp写东西，在第一个环境的序列比较超前时，它已经在该目录里面创建了o0003167.tmp，我再在第二个环境发起请求的时候，它再创建o0003167.tmp的时候就会创建失败。
总结：
当一台服务器上运行了多套环境时，不能使用/usr/tmp作为$APPLPTMP，须定义成各自的目录。且该目录须在数据库参数utl_file_dir中。
另：前面是摘自其它人的博客，后来又问了一下同事，utl_file_dir数据库参数，其第一个值可以不是/usr/tmp，报这个错误也有可能是tmp文件夹满了的，清空一下就可以了！今天在运行请求时候得到如下的错误日志：
原因：由于ORA-20100:为FND_FILE创建文件o0003167.tmp失败。
在请求日志的错误原因中您会找到更详细的信息。
查找了一些资料，总结了一下出问题的原因。
1.查看$APPLPTMP系统环境变量的值，一般是/usr/tmp，需要保证该文件夹是存在的。
2.查看utl_file_dir数据库参数，其第一个值也应该为/usr/tmp;
SELECT * FROM V$PARAMETER V WHERE v.NAME='utl_file_dir'
3.查看该文件夹的权限，该文件夹必须为应用用户和数据库用户都具有读写权限。
4.通过exec FND_FILE.PUT_LINE(FND_FILE.LOG, 'THIS IS A TEST');进行测试，查看是否能输入文件。
我做了上面的四个步骤，发现4能正常运行结束，我为什么请求上会报错呢？最后终于找到了原因，我是一台服务器上面装了两套环境的应用，环境管理员在刻环境的时候，没有修改$APPLPTMP的值，导致两个环境都往/usr/tmp写东西，在第一个环境的序列比较超前时，它已经在该目录里面创建了o0003167.tmp，我再在第二个环境发起请求的时候，它再创建o0003167.tmp的时候就会创建失败。
总结：
当一台服务器上运行了多套环境时，不能使用/usr/tmp作为$APPLPTMP，须定义成各自的目录。且该目录须在数据库参数utl_file_dir中。
参考：http://blog.163.com/wangbin_bonnie/blog/static/12943869200992133328633/
另：前面是摘自其它人的博客，后来又问了一下同事，utl_file_dir数据库参数，其第一个值可以不是/usr/tmp，报这个错误也有可能是tmp文件夹满了的，清空一下就可以了！
If a PL/SQL Concurrent Program can't write to an external file, you will receive an error message similar to:
MSG-00102: Error Message :ORA-20100: File o0000071.tmp creation for FND_FILE failed.
You will find more information on the cause of the error in request log.
ORA-06512: at "APPS.FND_FILE", line 378
ORA-06512: at "APPS.FND_FILE", line 473
ORA-06512: at "APPS.AP_TRIAL_BALANCE_PKG", line 192
REP-1419: 'beforereport': PL/SQL program aborted.
NOTE: Applications also produces temporary PL/SQL output files used in concurrent processing. These files are written to a location on the database server node specified by the APPLPTMP environment setting. The APPLPTMP directory must be the same directory
as specified by the utl_file_dir parameter in your database initialization file.
.
Rapid Install sets both APPLPTMP and the utl_file_dir parameter to the same default directory. As the temporary files placed in this directory may contain context sensitive information, it should be a secure directory on the database server node with read and
write access for the database server owner. In a multi-node system, the directory defined by APPLPTMP does not need to exist on the application tier servers. During an upgrade with AutoUpgrade, you must provide the utl_file_dir parameter value for the APPLPTMP
environment setting.
To isolate where the problem is, verify the following:
1) Make sure that the name of the file is valid (the file name should not include characters like "^")
2) Make sure that APPLPTMP is set to a valid directory and that BOTH the applmgr user and the database user have read and write permissions on that directory (normally, it can be set to the same directory as APPLTMP)
3) Make sure that the file does not exit on the directory pointed by APPLPTMP
4) Make sure the directory pointed by APPLPTMP is the first entry on the utl_file_dir. Also, verify that all the entries on the utl_file_dir are valid and that the applmgr has read/write permissions.
If using an spfile, verify the proper syntax to set utl_file_dir:
Ex.
ALTER SYSTEM SET UTL_FILE_DIR='directory1','directory2' scope=spfile;
5) If still having problems, check if you can write a file directly using FND_FILE, which is the package used by the Application. From sqlplus, connected as the apps user, run:
SQL> exec FND_FILE.PUT_LINE(FND_FILE.LOG, 'THIS IS A TEST');
This should dump a file on APPLPTMP.
If this test works, it would indicate that FND_FILE is ok and the problem is possibly with the Application.
You may want to leave only one entry on utl_file_dir for this test.
6) If still having problems, check if you can write a file using UTL_FILE, which is used by FND_FILE.
Run the PL/SQL below, changing <first entry on utl_file_dir> to the first entry on utl_file_dir (you may want to leave just one entry on utl_file_dir for this test).
set serveroutput on
DECLARE
file_location VARCHAR2(256) := '';
file_name VARCHAR2(256) := 'utlfile1.lst';
file_text VARCHAR2(256) := 'THIS IS A TEST'; BEGIN
file_id := UTL_FILE.fopen(file_Location, file_name, 'W');
UTL_FILE.put_line(file_id, file_text);
UTL_FILE.fclose(file_id);
EXCEPTION
WHEN UTL_FILE.INVALID_PATH
THEN dbms_output.put_line('Invalid path ' || SQLERRM);
WHEN OTHERS
THEN dbms_output.put_line('Others '|| SQLCODE || ' ' || SQLERRM);
END;
/
This program should dump a file on the requested directory. If the test fails, the problem is probably on the Database side.
If it works, the problem is probably on FND_FILE. In this scenario, check the versions of AFCPPIOS.pls and AFCPPIOB.pls.