Concurrent Processing

Overview of Concurrent Processing

This section explains how a request to run a concurrent program is handled by Oracle Applications, and what the life cycle of a concurrent request is. In Oracle Applications, concurrent processing simultaneously executes programs running in the background with online operations. As System Administrator, you can manage when programs are run and how many operating system processes Oracle Applications devotes to running programs in the background.

Concurrent Requests, Programs, and Processes

When a user runs a report, a request to run the report is generated. The command to run the report is a concurrent request. The program that generates the report is a concurrent program. Concurrent programs are started by a concurrent manager. Figure 1 - 11.

Concurrent Managers start concurrent programs

Every time your users request a concurrent program to be run, their request is inserted into a database table, and is uniquely identified by a request ID. Concurrent managers read requests from this table. Part of a manager's definition is how many operating system processes it can devote to running requests. This number is referred to as the manager's number of target processes.

Running concurrent programs

A concurrent program actually starts running based on:

• When it is scheduled to start

• Whether it is placed on hold,

• Whether it is incompatible (cannot run) with other programs

• Its request priority

Concurrent Request Priorities

The priority of a concurrent request is determined by application username, and is set by the System Administrator using the Concurrent:Priority user profile option. The first available concurrent manager compares the request's priority to other requests it is eligible to process, and runs the request with the highest priority.
When choosing between requests of equal priority, the concurrent manager runs the oldest request first.

Parent requests and Child requests

Often, several programs may be grouped together, as in a request set. Submitting the request set as a whole generates a request ID, and as each member of the set is submitted it receives its own request ID. The set's request ID identifies the Parent request, and each of the individual programs' request ID identifies a Child request.
  

Life cycle of a concurrent request

A concurrent request proceeds through three, possibly four, life cycle stages or phases:

Pending	Request is waiting to be run
Running	Request is running
Completed	Request has finished
Inactive	Request cannot be run

Within each phase, a request's condition or status may change. Below appears a listing of each phase and the various states that a concurrent request can go through.
Concurrent Request Phase and Status

Phase	Status	Description
PENDING	Normal	Request is waiting for the next available manager.
	Standby	Program to run request is incompatible with other program(s) currently running.
	Scheduled	Request is scheduled to start at a future time or date.
	Waiting	A child request is waiting for its Parent request to mark it ready to run. For example, a report in a report set that runs sequentially must wait for a prior report to complete.
RUNNING	Normal	Request is running normally.
	Paused	Parent request pauses for all its child requests to complete. For example, a report set pauses for all reports in the set to complete.
	Resuming	All requests submitted by the same parent request have completed running. The Parent request is waiting to be restarted.
	Terminating	Running request is terminated, by selecting Terminate in the Status field of the Request Details zone.
COMPLETED	Normal	Request completes normally.
	Error	Request failed to complete successfully.
	Warning	Request completes with warnings. For example, a report is generated successfully but fails to print.
	Cancelled	Pending or Inactive request is cancelled, by selecting Cancel in the Status field of the Request Details zone.
	Terminated	Running request is terminated, by selecting Terminate in the Status field of the Request Details zone.
INACTIVE	Disabled	Program to run request is not enabled. Contact your system administrator.
	On Hold	Pending request is placed on hold, by selecting Hold in the Status field of the Request Details zone.
	No Manager	No manager is defined to run the request. Check with your system administrator.

How To View Request Status and Output

Use any of the following methods to view the status and output of concurrent requests.

Use the Requests Window

Use the Requests window to view the status of concurrent requests, and to view request log and report output files.

The System Administrator and Oracle Alert Manager have a privileged version of the Requests window that provides you with more capabilities than your end users. For example, using the Requests window, you can view the status of and log files for all concurrent requests (not just your own), including requests that completed unsuccessfully. On some platforms, you can even view the log files of running requests.
Using the same window, you can view your own report output online. You cannot, however, view report output from other users' requests.
From the Requests window, you can also:

• place and remove holds from any pending or inactive request

• cancel a pending request, or terminate a running request

• change the priority of any pending request

• view the manager log file

• determine where any pending request stands in the queue for each manager defined to accept the request

• determine when the Internal Concurrent Manager is inactive and needs to be restarted.

Run the Completed Concurrent Requests Report

You can run a report that lists parameters and any error messages associated with concurrent requests that have completed running.

 

How to Modify Request Diagnostic Output

The Request Diagnostics window provides the user with request status information. This information consists of messages that explain the request's current status. You can enhance the information provided to include runtime statistics (CPU time) collected from previous runs of the request.

Collect Runtime Data

Set the profile option Concurrent:Collect Request Statistics to "Yes" to collect runtime statistics. A concurrent request may be comprised of one or two processes: a sql*net shadow which consumes database server resources, and a front-end process such as a C executable. The time used by the CPU is collected for both of these types of processes.

Summarize and View Runtime Statistics

To review the statistics you must run the Purge Concurrent Request and/or Manager Data program to process the raw data and have it write the computed statistics to the FND_CONC_STAT_SUMMARY table. You can review the statistics on a request by request basis using the Diagnostics window from the Requests window.

Setting End User Report and Log File Access Privileges

The user profile option Concurrent:Report Access Level determines report output file and log file access privileges for your end users. As System Administrator, you can set this profile option to either "User" or "Responsibility". All users can can review the log and report output files from requests that they submitted.
If you set the Concurrent:Report Access Level option to "Responsibility" at the User level, that user can also review the log and report output files from all requests submitted from the current responsibility.
If you set the Concurrent:Report Access Level option to "Responsibility" at the Responsibility level, any user of a responsibility can also view the log and report output files from all requests submitted by any other user of that responsibility.

Managing Concurrent Processing Files and Tables

This section explains how to maintain the number of log and output files the operating system retains, and how to manage Application Object Library database tables that store information about concurrent requests and concurrent manager processes. The database tables that are affected by running the Purge Concurrent Request and/or Manager Data program are:

FND_CONCURRENT_REQUESTS

This table contains a complete history of all concurrent requests.

FND_RUN_REQUESTS

When a user submits a report set, this table stores information about the reports in the report set and the parameter values for each report.

FND_CONC_REQUEST_ARGUMENTS

This table records arguments passed by the concurrent manager to each program it starts running.

FND_DUAL

This table records when requests do not update database tables.

FND_CONCURRENT_PROCESSES

This table records information about Oracle Applications and operating system processes.

FND_CONC_STAT_LIST

This table collects runtime performance statistics for concurrent requests.

FND_CONC_STAT_SUMMARY

This table contains the concurrent program performance statistics generated by the Purge Concurrent Request and/or Manager Data program. The Purge Concurrent Request and/or Manager Data program uses the data in FND_CONC_STAT_LIST to compute these statistics.

Maintenance Suggestions

Your MIS department and application users should agree on an archiving and file retention policy that is appropriate for your organization. To avoid running out of space on your disk drives, you should periodically delete Oracle Applications log files and output files.

Suggestion: You can run the program "Purge Concurrent Request and/or Manager Data" once and automatically resubmit the program for you at specific time intervals.

There are some sample guidelines for when to run the Purge Concurrent Requests and/or Manager Data program. Adopt these guidelines according to your user community's usage of Oracle Applications.

• every 30 days for normal usage

• every two weeks (14 days) for heavy usage

• if using the AGE mode, set the Mode Value to 5 to retain the five most recent days of concurrent request data, log files, and report output files.

Purging loses Audit data

When you purge concurrent request information, you lose audit details. The Signon Audit Concurrent Requests report uses this audit information.