Log and output files must have specific names and locations for users to review the files online.
For custom concurrent programs discussed later, if you use the Oracle Application Object Library routine fdpwrt() to write to files, the concurrent managers automatically name the files according to the operating system's naming conventions. This method of writing to files is completely portable. You do not have to rewrite your programs to name your log and output files differently if you port your application to another platform.
Standard names for log and output files are listed in the following table:
| File Type | File Name |
|---|---|
| Log | l<request ID>.req |
| Output | Default: <USERNAME>.<request ID> or O<request ID>.out or user.out based on value of APPCPNAM |
The variable parameters shown in this table have the following values:
<PROD>_TOP - The application's top environment variable.
<Request ID> - The number that identifies the concurrent request.
<USERNAME> - Up to eight characters (uppercase) of the application username of the person who requested the concurrent process.
On UNIX platforms, the filenaming works as described in the following table:
| APPCPNAM Variable Assignment in UNIX | Output File Format |
|---|---|
| APPCPNAM = "REQID" | o999999.out |
| APPCPNAM = "USER" | <Applications user>.out |
| APPCPNAM = "USER.REQID" | <Applications user>.999999 |
| (unset or unrecognized syntax) | o999999.out |
In the above table, <Applications user> refers to an Oracle E-Business Suite user name and '999999' stands for a concurrent request ID.
On Windows platforms, the default format is o<request ID>.out. Setting APPCPNAM to USER on a Windows platform results in the output files having the format <user ID>.out.
Beginning with Release 12.2.6, Oracle E-Business Suite provides a choice of storage strategies for management of large numbers of concurrent processing log and output files. Customers can specify the strategy that best suits their particular needs. These strategies are called schemes.
All log and output files are kept under $APPLCSF. Regardless of the scheme chosen, $APPLCSF will always be the top level directory.
The scheme is determined by the $APPLLDM environment variable. Before Release 12.2.6, this variable had two settings: 'single' and 'product'. These two schemes remain valid and 'single' is still the default scheme.
If $APPLLDM is unset, the managers will default to using 'single'. When $APPLLDM is defined but invalid, request log/output files will go to $APPLCSF/log|out, and manager logs will go to $APPLCSF/system/log.
The value of $APPLLDM can be changed in the standard way or using the cpadmin utility. All managers must be shut down before changing the value of $APPLLDM.
Because there is typically not the same volume of manager log files as there are request log files/output files, manager logs will not be kept with request log files; rather, they will be kept in the $APPLCSF/system/log directory. This strategy is identical to the 'product' scheme. The exception to this rule is the 'single' scheme. If this scheme is used, all manager logs will still be kept in $APPLCSF/log (unchanged from earlier releases).
In regard to purging, the purge program, "Purge Concurrent Request and/or Manager Data" (FNDCPPUR), will purge files no matter what their location is. Using a scheme that involves creating new directories may leave empty directories around after running a purge. You should clean up these directories after running a purge.
Note: Files will not be rotated or moved once they are created.
The naming format for schemes is SCHEME:parameter where SCHEME is the name of the scheme and parameter is an optional parameter, separated by a colon.
Some schemes do not take a parameter, others may require a parameter. If a parameter is optional or has a default value it will be noted.
Scheme names are not case sensitive.
This is the default scheme. This scheme takes no parameters. Request log files will go into $APPLCSF/logand log files will go into $APPLCSF/out. Manager logs will go into $APPLCSF/log directory. These directories must exist before starting managers.
This scheme takes no parameters. Request log and out files will go to$APPLCSF/<product short name>/log and $APPLCSF/<product short name>/out, respectively. Manager logs will go into the $APPLCSF/system/log directory. These directories must exist before starting managers.
Takes no parameters. Requests log and out files will go to $APPLCSF/<user name>/log and $APPLCSF/<user name>/out, respectively. Manager logs will go into the $APPLCSF/system/log directory. User name directories need not exist when starting managers. The system directory must exist before starting managers, however.
date:<string> (required)
This scheme takes a string as a required parameter.
Valid values are same as C function strftime() with following exceptions.
Resulting string must not include special characters, spaces, wild cards, or directory delimiters such as /and \. The characters . and .. are also prohibited.
Resulting string must only create one level of directory Therefore, a string such as %Y/%m/%d is invalid whereas %Y-%m-%d is valid. It will result in directory 2016-01-25, for example.
Requests log and out files will go to $APPLCSF/<resulting string>/log and $APPLCSF/<resulting string>/out, respectively. Manager logs will go to the $APPLCSF/system/log directory. Date directories need not exist when starting managers. The system directory must exist before starting managers.
reqidexp:<integer> (required)
This scheme takes an integer value for a parameter. Valid values are all positive integers; however, reasonableness of that figure must be assured by the user. Zero is a valid value; however, every request will be placed on its own directory making it meaningless in most cases.
Consider this formula:
result = int(request_id / 10^(parameter)) * 10^(parameter)
If argument is 1, request 12345 will be placed in 12340
If argument is 2, request 12345 will be placed in 12300
If argument is 3, request 12345 will be placed in 12000
Requests log and out files will go to $APPLCSF/<resulting string>/log and $APPLCSF/<resulting string>/out, respectively. Manager logs will go to $APPLCSF/system/log directory. These derived directories need not exist when starting managers. System directory must exist before starting managers.
reqidmod:<integer> (required)
This scheme takes an integer value for a parameter. Valid values are all positive integers except for zero. Using 1 is meaningless in most cases as it will only create one directory. The value must also be reasonable; see below.
Managers will create specified n number of directories starting with 0 (zero) and continue with other numbers in sequential order. Then, each manager process will perform the following function to determine log and output location.
result = request_id mod <parameter>
If argument is 1, directory 0 will be created. Request 12345 will be placed in this directory.
If argument is 2, directories 0 and 1 will be created. request 12345 will be placed in directory 1. This scheme will result in directory 0 for even numbered request_ids and 1 for odd numbered request_ids.
If argument is 3, directories 0, 1, and 2 will be created. Request 12345 will be placed in directory 0, 12346 will be placed in directory 1, and 12347 will be placed in 2. Using large number will result in large number of directories.
Using numbers larger than current request_id will result in having one directory for each result and empty directories.
Requests log and out files will go to $APPLCSF/<resulting string>/log and $APPLCSF/<resulting string>/out, respectively. Manager logs will go to $APPLCSF/system/log directory. These derived directories need not exist when starting managers. The system directory must exist when starting managers.
This scheme takes no parameters.
Requests log and out files will go into $APPLCSF/<manager's process ID>/log and $APPLECSF/<manager's process ID>/out, respectively. Therefore, each manager's process will have its own directory. Please note that the manager's process ID is not the UNIX PID or other operating system derived numbers. It refers to process ID generated when the manager was started. This number is represented as Manager ID in the Administer Concurrent Managers > Processes window, and is also used as part of the manager's log file names.
Manager logs will go to $APPLCSF/system/log directory. The derived directories need not exist when starting managers. The system directory must exist before starting managers.