What FND Tables Store All Concurrent Program Information Details

The tables which store concurrent program details are:-


FND_CONCURRENT_PROGRAMS:- 
FND_CONCURRENT_PROGRAMS stores information about concurrent programs. Each row includes a name and description of the concurrent program. Each row also includes the execution methods for the program (EXECUTION_METHOD_CODE), the argument method ARGUMENT_METHOD_CODE), and whether the program is constrained (QUEUE_METHOD_CODE).

If the program is a special concurrent program that controls the concurrent managers, QUEUE_CONTROL_FLAG is set to Y. Each row also includes flags that indicate whether the program is enabled and defined as run-alone, as well as values that specify the print style the concurrent manager should use to print program output, if any.
There are also values that identify the executable associated with the concurrent program and the application with which the executable is defined, and flags that specify whether the concurrent program is a parent of a report set, whether to save the output file, and whether a print style is required. Information such as printer name and number of rows and columns on each page of the output file for the concurrent program is also included in the table.  You need one row for each concurrent program in each application.  Oracle Application Object Library uses this information to run concurrent programs.

FND_CONCURRENT_PROGRAMS_TL:-
FND_CONCURRENT_PROGRAMS_TL stores translated information about concurrent programs in each of the installed languages.  Each row includes the language the row is translated to. Each row also includes identifiers which identify the concurrent program and the application the concurrent program is registered with, and the description and title of the concurrent program. You need one row for each concurrent program in each of the installed languages.

FND_CONCURRENT_REQUESTS:-
FND_CONCURRENT_REQUESTS stores information about individual concurrent requests. Each row includes values that identify the particular request and its parameters, such as who submitted it,
the request type, whether the request should run sequentially with other requests in the same logical database (SINGLE_THREAD_FLAG), whether the request is on hold (HOLD_FLAG), whether to display the request in the View Requests form for the request submitter to review, and what status and phase the concurrent request is in.
Each row also includes values that identify the concurrent program, its execution and argument methods, and whether the program is constrained (QUEUE_METHOD_CODE). Each row also includes flags that indicate the request's priority relative to other requests, as well as values that specify how the concurrent manager should print program output, if any. ARGUMENT1 through ARGUMENT25 contain any arguments the application passes to the concurrent program. If the
concurrent program needs more than 25 arguments to run, the first 25 arguments are stored in this table, ARGUMENT26 through ARGUMENT100 are stored in FND_CONC_REQUEST_ARGUMENTS. ARGUMENT_TEXT contains the concatenation of concurrent request arguments and COMPLETION_TEXT contains a message about how the request completed. The row also contains dates that the request was submitted, requested to start and actually run. REQ_INFORMATION is used with report sets to remember the status of the request between runs.

When the request is set to use automatic resubmission, RESUBMITTED is a flag to indicate whether the request has been resubmitted or not. RESUBMIT_INTERVAL_TYPE_CODE specifies whether to start interval count down from the requested start time or the completion of the
request. RESUBMIT_INTERVAL_UNIT_CODE indicates whether interval unit is in Days, Hours, Minutes, or Months. RESUBMIT_TIME sets the time of the day to rerun the concurrent request. RESUBMIT_INTERVAL indicates the number of units of time when the identical request will be resubmitted. RESUBMIT_END_DATE is the date the request stops resubmitting itself. IS_SUB_REQUEST is a flag that identifies a child request and HAS_SUB_REQUEST is a flag that
identifies a parent request. Each child request also needs to have values in ARENT_REQUEST_ID to show what parent request submitted the child request and PRIORITY_REQUEST_ID to tell what priority the parent request has and what priority the child request should have.

Oracle Application Object Library does not use ENFORCE_SERIALITY_FLAG (always Y), CPU_SECONDS, LOGICAL_IOS, or PHYSICAL_IOS. You need one row for each concurrent request. Though you should occasionally delete from this table, you should not modify any of its data.   Oracle Application Object Library uses this information to run concurrent requests, and automatically updates it as requests change their status.