This section explains how a request to run a concurrent program is handled by Oracle E-Business Suite, and what the life cycle of a concurrent request is.
In Oracle E-Business Suite, 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 E-Business Suite devotes to running programs in the background.
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.
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.
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
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.
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.
A concurrent request proceeds through three, possibly four, life cycle stages or phases:
Variable | Description |
---|---|
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. The following table shows a listing of each phase and the various states that a concurrent request can go through.
Phase | Status | Description |
---|---|---|
PENDING | Normal | Request is waiting for the next available manager. |
PENDING | Standby | Program to run request is incompatible with other program(s) currently running. |
PENDING | Scheduled | Request is scheduled to start at a future time or date. |
PENDING | 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. |
RUNNING | 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. |
RUNNING | Resuming | All requests submitted by the same parent request have completed running. The Parent request is waiting to be restarted. |
RUNNING | Terminating | Running request is terminated, by selecting Terminate in the Status field of the Request Details zone. |
COMPLETED | Normal | Request completes normally. |
COMPLETED | Error | Request failed to complete successfully. |
COMPLETED | Warning | Request completes with warnings. For example, a report is generated successfully but fails to print. |
COMPLETED | Cancelled | Pending or Inactive request is cancelled, by selecting Cancel in the Status field of the Request Details zone. |
COMPLETED | 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. |
INACTIVE | On Hold | Pending request is placed on hold, by selecting Hold in the Status field of the Request Details zone. |
INACTIVE | No Manager | No manager is defined to run the request. Check with your system administrator. |
Related Topics
Reviewing Requests, Request Log Files, and Report Output Files
How to View Request Status and Output
Setting End User Report and Log File Access Privileges
Managing Concurrent Processing Files and Tables
An Oracle E-Business Suite system depends on a variety of services such as Concurrent Managers and Workflow Mailers. Such services are composed of one or more processes that must be kept running for the proper functioning of the applications. Previously many of these processes had to be individually started and monitored by system administrators. Management of these processes was complicated by the fact that these services could be distributed across multiple host machines. Service Management helps to greatly simplify the management of these processes by providing a fault tolerant service framework and a central management console built into Oracle Applications Manager.
Generic Service Management (GSM, or simply Service Management) is an extension of concurrent processing, which provides a powerful framework for managing processes on multiple host machines. With Service Management, virtually any application tier service can be integrated into this framework. Services such as the Oracle Workflow Mailer or Java services can be managed under Generic Service Management.
With Service Management, the Internal Concurrent Manager (ICM) manages the various service processes across multiple hosts. On each host, a Service Manager acts on behalf of the ICM, allowing the ICM to monitor and control service processes on that host. System administrators can then configure, monitor, and control services though a management console which communicates with the ICM.
Generic Service Management
Service Management provides a fault tolerant system. If a service process exits unexpectedly, the ICM will automatically attempt to restart the process. If a host fails, the ICM may start the affected service processes on a secondary host. The ICM itself is monitored and kept alive by Internal Monitor processes located on various hosts.
Service Management provides significant improvements in the manageability of Oracle E-Business Suite. System administrators can now use the central console in Oracle Applications Manager (OAM) to manage a variety of services that formerly had to be managed independently on separate hosts. The entire set of system services may be started or stopped with a single action. Service Management also provides a great benefit by automatically compensating for certain system failures.
Service processes are very much like concurrent manager and transaction manager processes. They must be kept running on a middle tier for the proper functioning of their respective products. The concurrent processing management feature has been built for concurrent managers and transaction managers, to provide fault tolerance, process distribution, and simplified configuration and control.
The service processes will no longer need to be manually and individually started and monitored by Oracle E-Business Suite system administrators.
Services can take advantage of the process distribution and fault tolerance capabilities that have been developed for concurrent processing.
As with concurrent manager processes, system administrators can use work shifts to determine the number of processes that will be active for a service on a given node for a given time period.
To extend process management support to the various Applications services, the Internal Concurrent Manager must be able to start, monitor, and control processes on all Applications tiers. Every node of every tier will have an Oracle RPC-based Service Manager installed. The ICM will use the Service Manager to manage processes.
A service is a process or collection of processes that perform actions at the request of client processes. A concurrent manager is a type of service where the client submits a request for actions to be processed while the client continues to do other work.
While active, a service must have one or more listener processes that wait to process requests from clients. An example of a listener is a concurrent manager process which periodically polls a queue for requests to process.
Each service controlled by service management may have multiple service instances. Each instance may consist of one or more processes.
The Concurrent:GSM Enabled profile option should be set to Y to enable Service Management. It is set automatically to Y by AutoConfig. Disabling Service Management is not recommended as that may prevent necessary services from starting.
As part of its shutdown process, the ICM determines if it’s being forced to shutdown due to losing its database connection. This is done by looking for specific error messages ORA-3113, ORA-3114, or ORA-1041. If one of these error messages is detected, the ICM spawns the reviver process, which attempts to make a database connection. If unsuccessful, it sleeps for a period before trying again. This continues until either a successful connection is made or it receives a signal to shut itself down.
When a successful connection is made, the process kills the old ICM database session, and then starts a new ICM using the normal start manager script. Once the ICM is restarted, it starts up any other managers that had also shut down, and normal processing resumes.
Nodes can become overloaded when a middle-tier node fails and service instances on that node failover to their secondary nodes. The Load Distribution feature allows the System Administrator to control the allocation of resources during normal processing. The Failover Sensitivity feature allows Work Shifts to failover with fewer processes than on the original node. This lessens the impact on the existing resources allocated on the secondary node.
The number of failover processes is entered as part of the standard Work Shift settings in the Service Instance Definition. When failover occurs, the ICM uses the Failover Processes value in place of the normal running processes value as it iterates through service instances to perform queue sizing.
The Oracle Applications Manager allows administrators to manage E-Business Suite systems from an HTML console. Oracle Applications Manager can be used for a wide variety of tasks such as administering services including concurrent managers, examining system configuration, managing Oracle Workflow, examining applied patches, and measuring system usage.
Oracle Applications Manager provides diagnostic features for Applications systems. The console displays errors recently reported by system components such as transaction managers or concurrent requests. For running processes such as forms or concurrent requests, system administrators can examine the database session details, including any currently executing SQL.
Oracle Applications Manager allows administrators to configure, monitor, and control concurrent processing. Combined with the Service Management feature, Oracle Applications Manager can be used to monitor and control concurrent managers, as well as other application tier services.
Using the Oracle Applications Manager, you can:
view a summary of concurrent managers
view details of a concurrent manager
create or edit a concurrent manager
view a summary of concurrent requests
view details of a concurrent request
submit a concurrent request
search for a concurrent request based on its attributes, date submitted or completed, or its duration or wait time.
The Service Instances pages contain detailed information on the service instances for a particular service type, and display functions you can perform on the services.
Service types include, but are not limited to, the following:
Internal Concurrent Manager
Conflict Resolution Manager
Scheduler/Prerelease Manager
Request Processing Manager
Internal Monitor
Transaction Manager
The information and functionality available depends on the service type. Information may include the following:
Status - Click on the Status icon for a service to see more information.
State - The current state of a service. If you perform an action on that service, the state column value is updated.
Node - In a parallel concurrent processing environment, a service's processes are targeted to run on the node displayed here. If a service is defined to use a platform-specific system queue, this column displays the name of the queue to which the service submits its processes.
Number of Running Requests
Number of Pending Requests
Actual Processes - The number of operating system processes. Typically, the number of actual processes equals the number of target processes (the maximum number of requests a service can run). However, the number of actual processes may be less than the number of target processes service deactivation or service migration.
Target Processes - This column displays the maximum number of service processes that can be active for this service.
You can select a service instance and use the drop down menu above the table to perform the actions listed below. Or you can use the drop down menu at the top right to perform a single action on all service instances.
This page shows you information on service instances for a request processing manager. This type of manager runs concurrent requests.
Navigation: Applications Systems > System Activity > (Services region) Request Processing Manager
The following information is displayed:
Status
State
Node
Number of Running Requests
Number of Pending Requests
Actual Processes
Target Processes
Details (Show/Hide) - If you choose Show, the sleep interval will be displayed.
You can use the buttons at the top to perform the following on a selected service instance:
Delete
Edit
View Status
View Processes
View Concurrent Requests
To create a new service instance, use the Create New button.
You can start (activate) a service instance.
You can deactivate individual services. Once deactivated, a service does not restart until you select the service and choose the Start button.
When you deactivate a manager, all requests (concurrent programs) currently running are allowed to complete before the manager shuts down.
When you restart a manager, the processes are shut down and then brought back up.
You can abort or terminate individual services.
For concurrent managers, the following information is shown:
Node - the node on which the concurrent manager is running
Debug - this setting indicates whether debugging information is recorded in the concurrent manager log file. Set this option to "On" using the Set Debug On button to record debugging information.
Sleep Interval - the number of seconds your manager waits between checking the list of pending concurrent requests (concurrent requests waiting to be started).
Target
Active
Pending
Stand by
Running
The Processes page shows information on the concurrent processes of a service instance. You navigate to this page from the Service Instances page for a service.
Navigation: Site Map - Administration > Service Status (under Application Services) > (Services region) [Service] > (B) View Processes
You navigate to this page from the Service Instances page for a service.
The following information is given for each process:
Status - The status of the process. The following are valid statuses:
Active - Currently running service processes display as "Active".
Deactivated - Manager processes that were explicitly deactivated by a system administrator, either by deactivating the service or by shutting down the Internal Concurrent Manager.
Migrating - Services that are migrating between primary and secondary nodes display as "Migrating". In a parallel concurrent processing environment, services run on either the primary or secondary node assigned to them. Services migrate to the secondary node if the primary node or the database instance on the primary node is unavailable. Services migrate back to the primary node once it becomes available.
Terminating - service processes that are being terminated display as "Terminating". These processes were terminated by you choosing the Terminate button in the Administer Concurrent Managers form, by you choosing Abort in the Service Instances page, or by a user selecting "Terminate" in the Concurrent Requests form.
Terminated - service processes that have been terminated display as "Terminated". These processes were terminated by you choosing the Terminate button in the Administer Concurrent Managers form, by you choosing Abort in the Service Instances page, or by a user selecting "Terminate" in the Concurrent Requests form.
SPID - The operating system process ID associated with the service process.
AUDSID - The database session ID for the service process. If the AUDSID value appears as a link, you can click on the value to bring up the Database Session Information page.
Oracle SPID - The ORACLE system process ID associated with the service process.
Start Date - The start date for the process.
You can use the buttons to view the following:
Environment - The environment variable values for this service instance.
Manager Log - The manager log.
ICM Log - The Internal Concurrent Manager log.
This page can be added to the Support Cart.
This page shows you information on service instances for a service manager. Service managers perform actions on behalf of the Internal Concurrent Manager (ICM). They are controlled automatically by the ICM as needed and cannot be manually controlled.
Navigation: Applications Systems > System Activity > (Services region) Service Manager
The following information is displayed:
Status
State
Node
You can use the buttons at the top to perform the following on a selected service instance:
View Status
View Processes
This page shows you information on the service instance for the Internal Concurrent Manager (ICM).
Navigation: Applications Systems > System Activity > (Services region) Internal Concurrent Manager
The following information is displayed:
Status
State
Node
Number of Pending Requests - for the ICM, these are either service control requests (activate, deactivate, etc.) or requests marked for termination.
Details (Show/Hide) - If you choose Show, the sleep interval will be displayed.
You can use the buttons at the top to perform the following on the service instance:
View Status
View Processes
View Actions
Edit
You can select the service instance and use the drop down menu above the table to perform the actions below.
You can stop (deactivate) an individual service.
When you stop the Internal Concurrent Manager, all other managers are deactivated as well. Managers previously deactivated on an individual basis are not affected.
Any service that was active when the ICM was stopped will be restarted when the ICM is brought back up. Managers that were deactivated on an individual basis will not be brought back up with the ICM.
Use this function to stop all services.
Use this function to select which services you want to stop, and then stop only those services.
You can abort or terminate individual services.
When you abort (terminate) requests and terminate the Internal Concurrent Manager, all running requests (running concurrent programs) are terminated, and all managers are terminated. Managers previously deactivated on an individual basis are not affected.
Any service that was active when the ICM was aborted will be restarted when the ICM is brought back up. Managers that were deactivated on an individual basis will not be brought back up with the ICM.
The Internal Concurrent Manager periodically monitors the processes of each concurrent manager. You can force this process monitoring, or PMON activity, to occur by choosing the Verify action.
This page displays a list of the system's application tier services and their statuses. It also lists the number of actual processes and target processes.
Navigation: Applications Dashboard > System Activity (drop-down menu)
You can select a service and use the View Details button to view more information on that service, as well as perform certain actions on them.
Service Instances
Internal Concurrent Manager
Conflict Resolution Manager
Scheduler/Prerelease Manager
Request Processing Manager
Internal Monitor
Transaction Manager
Click the View All button to see all services listed. Click the View Set button to view the listing in sets of ten.
Click on the Activity Monitors tab to see information on Database Sessions and Concurrent Requests.
This page shows you information on service instances for the Conflict Resolution Manager (CRM).
Navigation: Applications Systems > System Activity > (Services region) Conflict Resolution Manager
The following information is displayed:
Status
State
Node
Number of Pending Requests - the number of Pending/Standby requests. For each Pending/Standby request, the CRM will evaluate the constraints (such as incompatibilities, single thread, user limit, etc.) and change the request to Pending/Normal when appropriate.
You can use the buttons at the top to perform the following on a selected service instance:
View Status
View Processes
View Concurrent Requests
Edit
You can select a service instance and use the drop down menu above the table to perform the actions below. Or you can use the drop down menu at the top right to perform a single action on all service instances.
You can use the Verify option for the Conflict Resolution Manager to force it to "re-cache" its information on incompatibilities among concurrent programs. Concurrent programs may be defined to be incompatible with other programs; that is, they should not run simultaneously with each other because they might interfere with each other's execution.
The Conflict Resolution Manager will also re-cache its information on users. A user may be assigned a maximum number of requests that may be run simultaneously using the "Concurrent: Active Requests Limit" profile option. The Conflict Resolution Manager rebuilds its list of users when you choose Verify.
This page shows you information on service instances for a Scheduler/Prerelease Manager. The Scheduler checks for and manages requests with advanced schedules.
Navigation: Applications Systems > System Activity > (Services region) Scheduler/Prerelease Manager
The following information is displayed:
Status
State
Node
Actual Processes
Target Processes
You can use the buttons at the top to perform the following on a selected service instance:
View Status
View Processes
Edit
You can use the dropdown list to Verify a Scheduler/Prereleaser Manager.
This page shows you information on service instances for an Internal Monitor. The purpose of an Internal Monitor is to monitor the Internal Concurrent Manager and restart it when it exits unexpectedly.
Navigation: Applications Systems > System Activity > (Services region) Internal Monitor
The following information is displayed:
Status
State
Node
Actual Processes
Target Processes
Details (Show/Hide) - If you choose Show, the sleep interval will be displayed.
You can use the buttons at the top to perform the following on a selected service instance:
Delete
Edit
View Status
View Processes
To create a new service instance, use the Create New button.
You can select a service instance and use the drop down menu above the table to perform the actions below. Or you can use the drop down menu at the top right to perform a single action on all service instances.
You can start (activate) a service instance.
You can deactivate individual services. Once deactivated, a service does not restart until you select the service and choose the Start button.
You can abort or terminate individual services.
This page shows you information on the transaction manager. service instances.
Navigation: Site Map > Transaction Managers (under Application Services)
The following information is displayed:
Details (Show/Hide) - Click Show to display the Sleep Interval setup for the selected Transaction Manager and the percent Estimated Availability. The sleep interval can be edited by clicking the Edit button.
Name - Drills down to the Service Instances Processes page.
Status - Drills down to the Status page for the selected transaction manager.
State - The current state of a service. If you perform an action on that service, the state column value is updated.
Node- In a parallel concurrent processing environment, a service's processes are targeted to run on the node displayed here. If a service is defined to use a platform-specific system queue, this column displays the name of the queue to which the service submits its processes.
Actual Processes - The number of operating system processes. Typically, the number of actual processes equals the number of target processes (the maximum number of requests a service can run). However, the number of actual processes may be less than the number of target processes due to service deactivation or service migration.
Target Processes - This column displays the maximum number of service processes that can be active for this service.
Timeouts - the number of timeouts that have occurred for this manager since its last activation.
You can use the buttons at the top to perform the following on a selected service instance:
Delete
Edit - Launches the Edit Manager page.
View Status - Launches the Status page.
View Processes - Launches the Service Instances Processes page.
To create a new service instance, use the Create New button.
The following features can help you diagnose transaction manager issues:
Use the drop-down list to set the debug level for the transaction manager. Choose one of the following options and click the Set Debug Level button. This will set the debug level for all Transaction Managers and will be enabled for future sessions.
Client side debugging
Both Client and Server side debugging
Server side debugging
Off
Note: Because debugging can adversely affect performance, it is important to turn it off when you are finished.
If a transaction manager is performing poorly, use the Time Transaction Manager feature to help diagnose the source of the problem. The Time Transaction Manager test reports the time consumed by each activity involved in a single transaction.
To run the test, select a transaction manager and click the Time Transaction button. This will invoke the Time Transaction Manager launch page. Click the Run Test button. The test results page will display the following information:
Elapsed Time - the total time required to complete the test.
Program - the test program name.
User - the user ID of the initiator of the test. Drills down to the User Details page.
Session ID
Transaction ID
Time - the time the activity began.
Source Type - the type of activity and whether it was initiated by the client or the server. If you activated client-side only or server-side only the test will show only those activities of the selected source. To see both, select Both Client and Server side debugging.
Action - description of the activity
Message - any message returned by the activity
Function - the PL/SQL function
Elapsed Time (in hundredths of seconds)
From this screen, click Finish Test to return to the Service Instances page, or click Purge to purge the debug information for the session.
You can select a service instance and use the drop down menu above the table to perform the actions listed below. Or you can use the drop down menu at the top right to perform a single action on all service instances.
Starts (activates) a service instance.
Deactivates individual services. Once deactivated, a service does not restart until you select the service and choose the Start button.
When you deactivate a manager, all transaction requests currently running are allowed to complete before the manager shuts down.
When you restart a transaction manager, its processes are shut down and then brought back up.
You can abort or terminate individual services.
The OAM Generic Collection Service is a generic service managed by Generic Service Management. It provides file uploading, signaling, purging, and other management for other service runtime processes such as the Forms Listener runtime process.
A running instance of the OAM Generic Collection service includes a main process which uses the java service cartridge API to consume the messages in the Generic Service Management Advanced Queue (AQ). After the service instance is started, it spawns four subprocesses:
Forms runtime instance upload process, which uploads the Forms runtime instance files from the node to the Oracle E-Business Suite database periodically based on the load interval.
On-demand runtime instance upload process, which uploads the Forms runtime instance files based on the custom message received from the AQ.
On-demand Forms Runtime Diagnostics (FRD) and termination signaling process, which signals the Forms runtime process to generate an FRD log for FRD messages, or terminates the runtime process, producing a termination message. The message is the custom message received from the AQ.
Forms runtime instance purge process, which purges the runtime instance tables and FRD log files. The numbers of days to keep these data are set as service parameters.
There is only one OAM Generic Collection Instance running per application system per node.
The OAM Generic Collection Service takes these parameters:
NODE: the name of the node on which the service runs.
LOADINTERVAL: the load interval for periodic runtime instance information uploading.
ORACLE_HOME: the ORACLE_HOME in which the Forms Listener runs.
RTI_KEEP_DAYS: the number of days to keep the runtime instance data in the database.
FRD_KEEP_DAYS: the number of days to keep Forms Runtime Log files.
Main Navigation Path: Site Map > Monitoring (subtab) > Performance (heading) > Concurrent Processing Charts (link)
Oracle Applications Manager offers a number of configurable charts for monitoring the performance of concurrent processing.
There are the following groups of charts:
Concurrent Requests
Concurrent Managers
Utilization
In the Concurrent Requests group, there are several charts, such as "Current Requests by Status," "Running Requests per Application," and "Pending Requests per Responsibility". In the Concurrent Managers group, there are charts such as "Pending Requests per Manager". In the Utilization group, there is a chart that depicts how many running requests and available processes exist per manager.
To view a chart, click its name in the table. In some cases, the charts are interactive and you can drill down on a particular bar or segment to see more details.
To set up a chart, click the Chart Setting icon. On the Change Chart Settings page, you can modify the chart type, refresh interval, and data items of a chart.
Navigation: Site Map - Monitoring > Concurrent Processing Reports (under Usage)
Launch the Concurrent Processing Activity Reports from this page. The concurrent processing statistics reports enable you to analyze historical trends relating to request runtimes, success rates, and individual user requests.
Concurrent Request Statistics by Program
Concurrent Request Statistics by Username
Concurrent Program Statistics by Name
Navigation: Site Map - Monitoring > Concurrent Processing Reports (under Usage) > Concurrent Request Statistics by Program
This report summarizes concurrent request statistics by program. These statistics can be useful when scheduling requests or balancing load across nodes (using specialization rules). This report is based on data in the fnd_concurrent_requests table, and is limited to the data in that table since the last time the table was purged using the "Purge Concurrent Request and/or Manager Data" concurrent program.
By default, the report displays data for the past week. Use the Search Criteria region to filter the results based on Application, Minimum Duration, and the reporting time period. The default sort order is by Total duration in descending order. All duration values are in minutes.
Application
Program
Total - the total of all individual runtimes for the program.
Average - the average runtime for this program.
Minimum - the shortest individual runtime for this program.
Maximum - the longest individual runtime for this program.
Times Run - the number of times this program has been run. This field drills down to the Search Results page showing the list of requests.
You can select a row for a concurrent program and click the Requests button to drill down to the Search Results page showing the list of requests.
Navigation: Site Map > Concurrent Processing (under Activity) > Concurrent Request Statistics by Username
This report summarizes the concurrent request statistics by username. These statistics can be useful to determine the usage pattern of different users. The columns displayed in the report are:
Username - click on the username to drill down to the User Details page.
Requests Completed (number) - drills down to the Search Results page showing the list of requests.
Total Runtime - the total runtime for all the requests submitted by the user (in hours).
By default, the report displays data for the past week grouped by username. Use the Search Criteria region to filter the results based on Username, Minimum Total Runtime, and the reporting time period.
You can select a row for a username and click the Requests button to drill down to the Search Results page showing the user's list of requests.
This page is accessed by drilling down on the Username field from those pages which display it.
The following contact information is displayed for the username (if available). Data is retrieved from the FND_USER table
User Name
Full Name
Phone
Phone
Fax
Navigation: Site Map > Monitoring > Concurrent Processing Reports (under Usage) > Concurrent Program Statistics by Name
This report provides a summary of statistics on concurrent programs. Summary information is collected when a request is completed, and stored in the table fnd_conc_prog_onsite_info.
Filter the display on this page by Application or Program name.
Note: Statistics recorded here are as of the Reset Date. The reset date can be viewed on the Program Runtime Statistics page.
The report includes the following fields:
Application - the application to which the concurrent request belongs
Program - the program name drills down to the Program Runtime Statistics page.
Average - the average runtime for this program in seconds.
Minimum - the shortest individual runtime for this program in seconds.
Maximum - the longest individual runtime for this program in seconds.
Times Run - the total number of times the report has been run.
Success Rate - the percent of the total requests that completed with a Normal status.
Total Time - the total runtime in seconds for all completed submissions of this program.
By default, the report is ordered by Times Run in descending order. Click the View Details button to display the Program Runtime Statistics page for the selected program.
The following fields are shown for the concurrent program selected from the Concurrent Program Statistics by Name page:
Last Run Date - the date and time this program was last run.
Last Run Request ID
Reset Date - the date and time from which these statistics have been gathered.
Times Successful - the number of times this program has completed with a status of Normal.
Times Warning - the number of times this program has completed with a status of Warning.
Times Error - the number of times this program has completed with a status of Error.
Oracle Applications Manager enables you to view details of concurrent requests. You can view concurrent requests by category or search for requests by specified criteria.
The Concurrent Requests pages can be accessed at:
Site Map > Monitoring > Concurrent Requests (under Current Activity)
Choose either Table View or Chart View. The Chart View displays a graph of the completed requests by Status.
The Table View displays the following fields:
Request ID
Short Name
Program Name
Completion Status - the status in which the request completed. Valid statuses are Normal, Error, Warning, Cancelled, and Terminated.
Requestor - drills down to the User Details page.
Duration - the amount of time required for the request to run in hours, minutes, and seconds (HH:MM:SS).
Started At - the time the request actually started running.
Also, you can click on "Show" under the Details column to see additional details for a request, such as
Printing information
Notification recipients
Parameters
Language
Submission time and Completion time
Schedule
Parent Request - if the request had a parent click this button to view details information about this request
Use the buttons to perform the following:
View Diagnostics for the request.
Launch the Request Log in a separate browser window.
Launch the Manager Log in a separate browser window.
View the Request Output.
The list of inactive requests is shown with the following information:
Request ID
Short Name
Program Name
Status - possible values are Disabled, On Hold, or No Manager.
Requestor - drills down to the User Details page.
Priority - The priority of the concurrent program to be run. A concurrent program may be given a priority when it is initially defined. However, you can assign a new priority to a request here by typing in the new value and clicking the Apply button.
Requested Start
Also, you can click on "Show" under the Details column to see additional details for a request, such as
Printing information
Notification recipients
Parameters
Language
Submission time
Schedule
Use the Remove Hold button to remove a hold on the inactive request.
Use the buttons to perform the following:
View Diagnostics for the request.
View Managers for the request.
Cancel the request.
Choose either Table View or Chart View. The Chart View displays a graph of the completed requests by Status.
The Table View displays the following fields:
Request ID
Short Name
Program Name
Status - possible values are Normal, Standby, Scheduled, and Waiting.
Requestor - drills down to the User Details page.
Priority - The priority of the concurrent program to be run. A concurrent program may be given a priority when it is initially defined. However, you can assign a new priority to a request here by typing in the new value and clicking the Apply button.
Wait Time - the amount of time after the Requested Start time that the program has been waiting to run.
Requested Start
Also, you can click on "Show" under the Details column to see additional details for a request, such as
Printing information
Notification recipients
Parameters
Language
Submission time
Schedule
Use the buttons to perform the following:
View Diagnostics for the request.
View Managers for the request.
Place the request on Hold.
Cancel the request.
Choose either Table View or Chart View. The Chart View displays a graph of the completed requests by Status.
The Table View displays the following fields:
Request ID
AUDSID - The database session ID for the request. Drills down to the Database Session Information page.
Short Name
Program Name
Requestor - drills down to the User Details page.
Responsibility
Duration
Also, you can click on "Show" under the Details column to see additional details for a request, such as
Printing information
Notification recipients
Parameters
Language
Submission time
Schedule
Use the buttons to perform the following:
View Diagnostics for the request.
View the Internal Manager Environment for the request.
View the Request Log.
View the Manager Log.
Cancel the request.
For completed, inactive, pending, and running requests, the following information is shown:
Phase - the phase may be Pending, Running, Completed, or Inactive
Status
If the phase is Pending, the status may be: Normal, Standby, Scheduled, or Waiting.
If the phase is Running, the status may be: Normal, Paused, Resuming, or Terminating.
If the phase is Completed, the status may be: Normal, Error, Warning, Cancelled, or Terminated.
If the phase is Inactive, the status may be: Disabled, On Hold, or No Manager.
Request ID
Diagnostics
For completed requests - provides a completion message and reports the begin and end times for the request.
For inactive requests - reports the date and time that the request became inactive and the reason for this status. Provides options based on the status.
For pending requests - reports the reason for the status of the request and options available to the system administrator.
This portion of the screen shows run time statistics for running, completed, and pending requests. All times are displayed in seconds.
Average - the average time required to run this request.
Minimum - the minimum time reported for the completion of this request.
Maximum - the maximum time reported for the completion of this request.
Estimated Completion - (displayed for running requests only) based on the statistics recorded for this request, the estimated time that the request will finish. If you need to shut down the system, use this indicator as a guide.
Actual - (displayed for completed requests only) the actual time required for this request to run.
This region of the page displays requests that are incompatible with the selected pending, running, or inactive request. Shown for each request are the following fields:
Show Details - click this link to drill down to request details.
Request ID
Program
Phase
Status
Requestor - click this link to drill down to the User Details page.
Reason - the reason the selected request is waiting on this request.
You can perform the following actions on the requests listed:
Hold - place the request on hold to allow the selected request to run.
Cancel - cancel the request to allow the selected request to run.
View - view the request details.
This page shows the environment variables and their values for the ICM environment. You can search for a particular variable using the filter.
Users can submit a single concurrent request for a single concurrent program to be run multiple times, each time in a different language. Any output that is produced can be routed to different printers based on language. Users can also route completion notifications based on the language of the output.
For example, a user could submit a request for a Print Invoices program that would cause that program to run several times, each time in a different language, with each set of invoices printed on a different printer.
When submitting requests with multilingual support (MLS), separate requests are actually submitted; one request for each language. To distinguish these requests in the UI, such as the Monitor Requests page, the request names are prefixed with "<ISO language code>-<territory>".
A concurrent program can have a Multilingual Support (MLS) function associated with it. This function determines the set of languages over which the concurrent program will run. For example, the developer might associate a function with a Print Invoices program that would cause any request for that program to run in the preferred languages of the customers who have pending invoices.
If the concurrent program does not have an MLS function associated with it, then a user can choose when submitting the request the list of languages in which the program should run. The language of the current session is the default language.
If a concurrent program does have an MLS function associated with it, users will not be able to select languages for their requests. The associated MLS function determines the languages in which the request will run.
Note: A concurrent program with an associated MLS function should have the "Use in SRS" box checked. If the "Use in SRS" box is not checked then the MLS function will be ignored. See: Concurrent Programs Window, Oracle E-Business Suite System Administrator's Guide - Configuration.
Multilingual requests behave similarly to request sets. A user submits a single request. When that request runs, it submits a child request for each language in its list of languages. The parent request remains in the Running/Waiting state until its child requests are completed. If any child request completes with error status, then the parent request completes with error status. If no children complete with error status, but one or more completes with warning status, then the parent completes with warning status. Finally, if all children complete with normal status, then the parent completes with normal status.
Developers can create an MLS function for concurrent programs. The MLS function determines in which of the installed languages a request should run. For example, an MLS function for a Print Invoices program could require that any request for that program to run only in the preferred languages of the customers who have pending invoices. This restriction saves system resources by assuring that the request does not run in languages for which no output will be produced. This restriction also prevents user error by automatically selecting the appropriate languages for a request.
MLS functions are PL/SQL stored procedures, written to a specific API. When the concurrent manager processes a multilingual request for a concurrent program with an associated MLS function, it calls the MLS function to retrieve a list of languages and submits the appropriate child requests for each language. The concurrent program application short name, the concurrent program short name, and the concurrent request parameters are all available to the MLS function to determine the list of languages that the request should be run in.
Beginning with Release 12.1, MLS functions can also support multiple territories and numeric character settings (",." for example).
MLS functions are registered in the Concurrent Program Executable form. A registered MLS function can be assigned to one or more concurrent programs in the Concurrent Programs form.
Related Topics
Oracle E-Business Suite User's Guide
Oracle E-Business Suite Concepts Guide
Oracle E-Business Suite Developer's Guide
The Oracle E-Business Suite organization model dictates how transactions flow through different organizations and how those organizations interact with each other. You can define multiple organizations and the relationships among them in a single installation of Oracle E-Business Suite. These organizations can be sets of books, business groups, legal entities, operating units, or inventory organizations.
Multiple organizations reporting improve reporting capabilities of Oracle E-Business Suite products by allowing reporting across operating units.
An operating unit is an organization that uses Oracle Cash Management, Order Management and Shipping Execution, Oracle Payables, Oracle Purchasing, and Oracle Receivables. An operating unit is associated with a legal entity and may be a sales office, a division, or a department. Information is secured by operating unit for these applications and each user sees information only for their operating unit. To run any of these applications, you choose a responsibility associated with an organization classified as an operating unit.
Note: The profile option MO:Operating Unit links an operating unit to a responsibility. You must set this profile option for each responsibility.
To run reports using multiple organizations reporting:
Navigate to the Submit Requests page.
Choose the report that you want to run.
A list of available operating units displays.
Choose the operating unit for this report.
Continue scheduling and submitting the request as usual.
Related Topics
Multiple Organizations in Oracle E-Business Suite
Concurrent processing uses the Output Post Processor (OPP) to enforce post-processing actions for concurrent requests. Post-processing actions are actions taken on concurrent request output. An example of a post-processing action is that used in publishing concurrent requests with XML Publisher. For example, say a request is submitted with an XML Publisher template specified as a layout for the concurrent request output. After the concurrent manager finishes running the concurrent program, it will contact the OPP to apply the XML Publisher template and create the final output.
The OPP runs as a service that can be managed through Oracle Applications Manager. One service instance of the OPP service is seeded by default. This seeded OPP service instance has one work shift with one process.
A concurrent manager contacts an available OPP process when a running concurrent request needs an OPP processing action. A concurrent manager uses a local OPP process (that, is, on the same node) by default, but will choose a remote OPP if no local OPP process is available.
There should always be at least one OPP process active in the system. If no OPP service is available, completed requests that require OPP processing will complete with a status of Warning.
An OPP service is multi-threaded and will start a new thread for each concurrent request it processes. You can control the number of simultaneous threads for an OPP service instance by adjusting the Threads per Process parameter for the instance. If all the OPP services have reached their respective maximum number of threads, the requests waiting to be processed remain in a queue to be processed as soon as threads become available. If request throughput has become slow, you may want to increase the number of threads per process for the OPP. It is recommended that you keep the number of threads per process between 1 and 20.
Oracle XML Publisher offers a feature called Delivery Manager which delivers documents through e-mail, fax, and other delivery channels. Users can direct the output of their concurrent requests to any of the channels that Delivery Manager supports. This capability is present for single requests and request sets using the Forms-based request submission UI, and for single requests in the HTML-based request submission UI.
For more information on Delivery Manager and related setup in Oracle XML Publisher, see the Oracle E-Business Suite online help.
Note: Delivery options using the HTML-based request submission UI is not supported currently for request sets.
In the Forms-based Standard Request Submission (SRS) window, users can enter their delivery options in a Delivery Options window available from a button in the "Upon Completion ... region in the SRS window. In the HTML-based request submission UI, delivery options in the Delivery step.
The following delivery channels are possible:
Internet Printing Protocol (IPP) Printer
Fax
FTP
At the time of request submission, a user can enter details for the chosen delivery option(s) as described below.
Username/Password - A user can enter a username and password for the selected IPP printer, if required. These will override any default values entered by the system administrator when the IPP printer was registered.
Copies - The number of copies. This must be greater than 0.
Orientation - Portrait or Landscape.
Language - Users can select a specific language or "All languages".
The email delivery option requires that an Simple Mail Transfer Protocol (SMTP) host and port be defined in the profiles FND: SMTP Host (FND_SMTP_HOST) and FND: SMTP Port (FND_SMTP_PORT), respectively. The profile values for these can be viewed and updated on the site and user level by a System Administrator, and can be viewed and updated by users themselves.
From - The user's default e-mail ID.
Subject - Populated with a default value composed of the Oracle E-Business Suite instance, program name, and name of the user submitting the request.
To add a recipient for the e-mail, the user must click the Add Another Row button and add recipients.
"To" Recipients - Required. Comma-separated e-mail IDs are supported.
"Cc" Recipients - Optional. Comma-separated e-mail IDs are supported.
For Language - The language for the report. If different languages are desired, additional rows can be used.
Printers that support faxing must be registered. See: Managing Delivery Options.
The Fax option here will list only those IPP printers that support faxing.
IPP Printer/Fax Server - Required.
Username/Password - A user can enter a username and password for the selected IPP printer, if required. These will override any default values entered by the system administrator when the IPP printer was registered.
Fax Number
For Language - The language for the report.
If different fax servers or languages are desired, additional rows can be used.
Both FTP and SFTP are supported. Secure FTP is indicated by checking the box "Secure FTP". Only password-authenticated SFTP is supported.
Host Name - Required.
Port - The default port value is 22.
User Name - Required.
Password - Required.
Remote Directory - Required. If this is left blank, the file is transferred to the remote home directory.
For Language - The language for the report.
Secure FTP
Additional rows can be used for sending output to additional servers.
Use the Manage Delivery Options page available under the System Administration responsibility to search for, register, update, or delete these options. Currently, only the IPP printer delivery type is available.
To search for a delivery option
You can search by delivery type.
Note: Currently, the only delivery type available is IPP Printer type.
You can search by the delivery name given by the user at the time of the delivery option creation.
To create (register) a delivery option
Enter a delivery name.
Enter a delivery type.
Note: Currently, only IPP Printer registration is supported.
Enter a host name an port. (Required)
Enter a username and password.
A system administrator can enter a default username and password which can be overridden by a user during request submission.
Enter a printer name. (Required)
Enter the number for sided printing.
The lookup codes in the following table are used:
Lookup Code | Meaning |
---|---|
1 | One-sided printing |
2 | Two-sided printing |
For the options Authentication, Encryption, Use Full URL, and Use Chunked Body, check the boxes as needed. These features are documented in the Delivery Manager documentation in the Oracle XML Publisher online help.
If the IPP Printer supports faxing, then the Support Fax box should be checked. This option will be used to enable the LOV for the fax server in the SRS Fax tab.
To update a delivery option
You can update a delivery option definition except for the delivery name and delivery type. These fields are read-only.
You can select a delivery option to update from the search results table in the Search page.
To delete a delivery option
You can delete a delivery option by selecting the Delete icon for it in the Search page. A confirmation message will be shown before deletion.
This essay explains how you, as System Administrator, can view and change the status of concurrent requests, and how to view request log and report output files.
Use any of the following methods to view the status and output of concurrent requests.
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
restart a request set.
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 concurrent manager is inactive and needs to be restarted.
You can run a report that lists parameters and any error messages associated with concurrent requests that have completed running. See: Completed Concurrent Requests Report, Oracle E-Business Suite System Administrator's Guide - Configuration.
The Request Diagnostics window provides the user with request status information. This information consists of messages that explain the request's current status.
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 Net8i 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.
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.
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 that responsibility can also view the log and report output files from all requests submitted by any other user of that responsibility.
The Oracle E-Business Suite Report File Viewer is used by default for viewing your text report files. You can also display text files in a browser or use another application such as Microsoft Word. You define your default viewer by setting a profile option.
If the Viewer:Text profile option is set to "Browser" then reports are sent to a web browser. If this profile option is left blank, the Report File Viewer is used instead.
If this profile option is left blank, a report or log file can still be viewed in a browser by first viewing it using the Report File Viewer, and then choosing "Copy File..." from the Tools menu.
You can view your reports with HTML output in a browser. Once an HTML report has been sent to a browser, it can be saved to the desktop by using the Save As functionality of the browser.
Note: HTML reports are displayed by the browser in the character set of the server. This character set may or may not match the character set on the client. Therefore, it may be necessary to convert the output to the client character set when saving the report. If the browser supports character set conversion with Save As, there will be a poplist in the Save As dialog box. The user can then choose an encoding which matches the client character set.
You can set up your Online Report Review implementation to enable viewing output files in other applications, such as Microsoft Word or Excel. To do this you associate MIME types with file output formats.
Users can then set their preferred MIME types for particular output formats using profile options, or the users may be prompted to choose the appropriate MIME type for a file at runtime.
You can register more than one MIME type file format with each output format. In the Viewer Options window, you enter in the file format, the MIME type, whether you want to utilize the value of the FND: Native Client Encoding profile option, and a description. The description is displayed to the user in the Profile Values window and the Submit Request form.
If the Allow Native Client Encoding box for the associated MIME type has been checked in the Viewer Options window, the Report Viewer will convert the output file into the character set specified by the profile option FND: Native Client Encoding.
When the report is viewed, it is first sent to a browser. The browser then uses the associated MIME type to display the report.
Important: For printing, if users choose either HTML or PDF as the output type with Oracle Report programs, they must use appropriate printer drivers to handle the PDF and HTML file for printing their output. See: Overview of Printers and Printing, Oracle E-Business Suite System Administrator's Guide - Configuration.
Note: For PDF files, the Adobe Acrobat Reader application must have options set as described below:
For Acrobat 4, under File > Preferences > General: uncheck Web browser integration.
For Acrobat 5 and 5.1, under Edit > Preferences: under options, unselect "Display PDF in Browser".
For Acrobat 6 and higher, under Edit > Preferences > Internet: under Web browser options, unselect "Display PDF in browser".
See: Viewer Options Window, Oracle E-Business Suite System Administrator's Guide - Configuration
This essay explains how to change a request's phase and status, and how to change the priority of a Pending or Inactive request. It also discusses how to restart request sets and how to prioritize requests by placing request sets on hold.
A request is in one of four phases: Pending (waiting to be run), Running, Completed, or Inactive (unable to run). Within each phase, a request's condition is referred to as its status.
You can change the phase of a Pending, Running, or Inactive request by changing its status.
You may cancel Pending and Inactive requests. The request's phase and status becomes Completed - Cancelled.
You may place on hold Pending and Inactive requests. The request's phase and status becomes Inactive - On Hold. You can reverse this action by later selecting the request removing the hold.
You can terminate Running requests. The request's phase and status becomes Completed - Terminated.
You can change the status of a request, and its resulting phase, using the Requests window.
Requests normally run according to start time, on “first-submitted, first-run" basis. However, a higher priority request starts before an earlier request.
As System Administrator, you can change the priority of any Pending or Inactive request using the Requests window.
The priority of a user's requests defaults to the value you, as System Administrator, set for their Concurrent:Priority user profile option. Users cannot change the priority of their requests.
If a concurrent program has a defined priority, that priority overrides the user's profile option.
Priorities range from 1 (highest) to 99 (lowest).
The standard default is 50.
Concurrent programs submitted by the Internal Concurrent Manager have a priority of zero (0), and override all other requests.
Tip: If you need to change the priority of a request frequently, you should consider assigning that concurrent program its own priority.
Related Topics
Overview of Concurrent Processing
Life cycle of a concurrent request
Concurrent Processing User Profile Settings
This section discusses how to restart request sets and how to yield a request set to higher priority requests.
If a request set completes with a status of Error, the Restart button, on the Oracle Applications Manager - View Completed Requests page is enabled. The system also automatically captures, records, and saves the information of the first stage that fails so that when the user clicks on the Restart button the request set can restart from that point.
Once the stage has been identified, the request set program submits the stage program in resubmit mode. In this mode, the program looks at the same stage from the previous run and determines which programs need to be rerun, (only those that ended in error), and runs those programs. If this stage completes successfully or has a Warning status, the system proceeds to the next stage using the normal mechanism of restarting the request set program.
Note: Users may restart a request set multiple times. The logs for each stage and individual programs are maintained independent of the number of runs as each stage and program submission generates a new request. However, the logs and associated files for a request set are rewritten each time the set is restarted.
In some circumstances, such as when a request set has a large number of stages and takes a long time to execute, administrators may want to yield a request set to higher priority requests. By utilizing the Hold Request Set feature, users can place a running request set on hold and effectively control the execution of request set stages.
The Hold and Remove Hold buttons are available on the OAM View Running Requests page. To hold a request set, simply select the request set and click the Hold button. Click Remove Hold when you want the request set to continue executing.
This essay explains how to control your concurrent managers.
Individual managers read requests to start concurrent programs and actually start programs running when certain conditions are satisfied, such as the manager's work shift definition, number of target processes, and specialization rules.
You can start, shut down, or reset the concurrent managers at any time. Oracle E-Business Suite provides an Internal Concurrent Manager that processes these commands. You can issue commands either to individual managers, or, by altering the state of the Internal Concurrent Manager, you can control every manager at once.
Note: Start your concurrent managers on machines with hostnames of 30 or fewer characters. Managers may fail to start on machines with longer hostnames.
You can restart or activate managers on an individual basis. Restarting a concurrent manager forces the Internal Concurrent Manager to reread the definition for that concurrent manager. Activating a manager cancels a previous command to deactivate it, and allows the Internal Concurrent Manager to submit a request to start that manager when its work shift starts.
You should restart an individual manager when you:
modify its work shift assignments
modify a work shift's target number of processes
modify its specialization rules
change a concurrent program's incompatibility rules
When you shut down an individual manager, you can choose whether to abort all requests and deactivate the manager immediately, or to allow it to finish processing its current requests before deactivating.
If you choose to Deactivate the manager, requests that are currently running are allowed to complete.
When you terminate requests and deactivate an individual manager, requests that are currently running are immediately stopped and marked for resubmission (when the manager is activated).
Oracle E-Business Suite concurrent programs are designed so that no data is lost or duplicated when a terminated request is resumed after a shut down. This applies for shutdowns that are normal (e.g., using the "Deactivate concurrent manager" request) or abnormal (e.g., after a hardware failure).
Important: When a manager is selected and explicitly deactivated, it remains that way until you select and explicitly activate that manager. As a prerequisite, the Internal manager must be activated beforehand.
When you activate the Internal Concurrent Manager, you activate all other managers as well, except those managers that were deactivated on an individual basis.
When you deactivate the Internal Concurrent Manager, it issues commands to deactivate all active managers. Managers that were deactivated on an individual basis are not affected.
If you terminate requests and deactivate the Internal Concurrent Manager, it issues commands to all other managers to terminate their requests and deactivate. Requests that are currently running are immediately stopped and marked for resubmission when the managers are activated.
The Internal Concurrent Manager continuously monitors each concurrent manager's operating system process. This process monitoring is referred to as the Internal Concurrent Manager's PMON cycle. The length of the PMON cycle is one of the arguments passed by the STARTMGR command, which starts up the Internal Concurrent Manager.
You can instruct the Internal Concurrent Manager to immediately verify the operating status of your individual concurrent managers, or to perform a PMON check.
Concurrent Managers are started from a Service Manager, which in turn is started by the Internal Concurrent Manager. You can set a threshold for the number of requests the Internal Concurrent Manager will make to start a concurrent manager after it fails to start.
During each ICM PMON cycle, the managers are verified and the system attempts to place a lock on each specific manager. If a manager is not up as expected, then the ICM submits a request to start it. However, a manager may have an underlying issue, such as a configuration issue or corrupted executable, that prevents it from starting. By setting a maximum number of attempts the ICM will make to start a manager over a set time, you can prevent the ICM from continuously making futile attempts to start these managers.
After the underlying problem is fixed, you can restart the manager from the Administer Managers window.
The startup threshold is defined by two profile options:
CONC: Manager Startup Threshold Limit - This value determines the number of attempts to restart a manager before the system will stop and alert the system administrator. The default value of this profile is 10 (attempts).
CONC: Manager Startup Threshold Time (minutes) - This value determines the length of time the attempts will be made to restart a manager. If the Threshold Limit as defined above is reached within this time limit, the attempts will stop until the underlying issue has been addressed. The default value of this profile is 60 minutes (1 hour).
If a manager has failed to start after the specified number of attempts (cycles), the manager will not be checked. You can fix the underlying problem, and after it is addressed, you can go to the Administer Managers window, select the manager, and click the Fixed button.
The concurrent manager startup threshold can be disabled by setting the profile option CONC: Manager Startup Threshold Limit to 0. This setting will cause the Threshold functionality to be ignored when managers are being checked for restarting.
Use the Administer Concurrent Managers form to issue commands to your concurrent managers.
You can also have the Internal Concurrent Manager "manually" verify the status of your individual managers, and restart individual managers. See: Administer Concurrent Managers, Oracle E-Business Suite System Administrator's Guide - Configuration.
The following table describes control functions for the Internal Manager.
Control Function | Description |
---|---|
Activate concurrent manager | Activates the Internal manager and all other managers, except managers that were deactivated individually using "Deactivate concurrent manager". |
Verify concurrent manager status | Manually executes the process monitoring (PMON) cycle. |
Deactivate concurrent manager | Deactivates the Internal manager and all other managers. |
Terminate requests and deactivate manager | All running requests (running concurrent programs) are terminated, and all managers are deactivated. |
The following table describes control functions for any other manager.
Control Function | Description |
---|---|
Activate concurrent manager | If the manager is defined to work in the current work shift, it starts immediately. Cancels "Deactivate concurrent manager" and "Terminate requests and deactivate manager". |
Restart concurrent manager | Internal manager rereads the manager's definition, and the rules for concurrent program incompatibilities. You should restart a manager when you: - Change work shift assignments - Modify the number of target processes - Modify specialization rules - Change concurrent program incompatibilities |
Deactivate concurrent manager | Deactivates the manager. All requests (concurrent programs) currently running are allowed to complete before the manager shuts down. A manager will not restart until you select the manager and choose "Activate concurrent manager". |
Terminate requests and deactivate manager | All running requests (running concurrent programs) handled by the manager are terminated. Once deactivated, a manager will not restart until you select the manager and choose "Activate concurrent manager". |
To start the Internal Concurrent Manager, use the shell script adcmctl.sh.
Alternatively, use one of two other commands you may use from the operating system to control the Internal Concurrent Manager: STARTMGR, which starts the Internal Concurrent Manager; and CONCSUB, which can be used to deactivate or abort the Internal Concurrent Manager, or to instruct the Internal Concurrent Manager to verify the operating system process for each individual manager.
The following table compares the Internal manager control states displayed by the Administer Concurrent Managers form with their corresponding operating system command. Not all arguments are shown.
From the Administer Concurrent Managers Form | From the Operating System (not all arguments shown) |
---|---|
Activate concurrent manager | STARTMGR (syntax may vary with platform) |
Verify concurrent manager status | CONCSUB FND VERIFY |
Deactivate concurrent manager | CONCSUB FND DEACTIVATE |
Terminate requests and deactivate manager | CONCSUB FND ABORT |
To start the Internal Concurrent Manager, use the shell script adcmctl.sh.
This command starts the Internal Concurrent Manager, which in turn starts any concurrent managers you have defined.
Alternatively, to start the concurrent managers, you can invoke the STARTMGR command from your operating system prompt.
You must have write privileges to the "out" and "log" directories of every application so that the concurrent managers can write to these directories. You can start the concurrent managers with many different options. An option on some operating systems is to send an electronic mail note to a given user when the concurrent managers shut down. See your installation guide for a discussion of this command.
Use the STARTMGR command:
during installation of Oracle E-Business Suite
after you shut down the concurrent managers
after MIS restarts the operating system
after the database administrator restarts the database
The STARTMGR command takes up to ten optional parameters.
Each parameter except PRINTER has a default.
You can modify the STARTMGR command and your environment to set your own defaults.
Enter the following command at your system prompt to start the Internal Concurrent Manager:
$ startmgr <optional parameters>
You can pass the parameters in any order. For example:
$ startmgr sysmgr="<username>/<password>" mgrname="std" printer="hqseq1" mailto="jsmith" restart="N" logfile="mgrlog" sleep="90" pmon="5" quesiz="10"
The startmgr script accepts an Oracle username/password as the sysmgr parameter. Alternatively, you could pass an Oracle E-Business Suite username/password as an appmgr parameter. If no sysmgr or appmgr parameter is provided on the command line, startmgr will prompt you for the Oracle password.
See: Setting Up Concurrent Managers, Oracle E-Business Suite System Administrator's Guide - Configuration
The Internal Concurrent Manager's log file displays startup parameter values executed by the STARTMGR command. An example is shown below. You cannot change the parameter values.
logfile=/fnddev/fnd/6.0/log/FND60.mgr (path is port-specific) PRINTER=hqunx138 mailto=appldev restart=N diag=N sleep=60 (default) pmon=20 (default) quesiz=1 (default)
From the operating system prompt, you can use the CONCSUB utility to submit a concurrent request, under the SYSADMIN username and the System Administrator responsibility.
The CONCSUB utility submits a concurrent request and returns you to the operating system prompt. You must wait until the concurrent request completes.
To check on the status of your concurrent request, use the Concurrent Requests form.
CONCSUB username/password 'Responsibility application shortname' 'Responsibility name' 'Username' [WAIT={Y|N|n}] CONCURRENT 'Program application shortname' PROGRAM
Variable | Description |
---|---|
username/password | The ORACLE username and password that connects to Oracle Application Object Library data. Alternatively, an Oracle E-Business Suite username and password for a user with the System Administrator responsibility. |
Responsibility application shortname | The application shortname of the responsibility. For the System Administrator responsibility, the application shortname is SYSADMIN. |
Responsibility name | The name of the responsibility. For the System Administrator responsibility, the responsibility name is System Administrator. |
Username | The application username of the person who submits the request. For example, SYSADMIN is the username of the System Administrator. |
WAIT={Y|N|n} | Set WAIT to Y if you want CONCSUB to wait until the request you submitted completes before CONCSUB returns you to the operating system prompt. Set WAIT to N (the default value) if you do not want CONCSUB to wait. You can also enter an integer value of n seconds for CONCSUB to wait before it exits. When used, WAIT must be entered before CONCURRENT. |
Program application shortname | The application shortname of the program. For the DEACTIVATE, ABORT, and VERIFY programs, the application shortname is FND. |
PROGRAM | To submit the Shutdown All Managers concurrent request, use the program DEACTIVATE. To submit the Shutdown Abort Managers concurrent request, use the program ABORT. To submit the Verify All Managers Status concurrent request, use the program VERIFY. |
CONCSUB <Username/Password> SYSADMIN 'System Administrator' SYSADMIN CONCURRENT FND DEACTIVATE
CONCSUB <Username/Password> SYSADMIN 'System Administrator' SYSADMIN CONCURRENT FND ABORT CONCSUB <Username/Password> SYSADMIN 'System Administrator' SYSADMIN CONCURRENT FND VERIFY
Use CONCSUB to shut down the concurrent managers:
before MIS shuts down the operating system
before the database administrator shuts down the database
when you want concurrent manager and concurrent program definitions to take effect
Then, use the STARTMGR command to restart the Internal Concurrent Manager, which starts the concurrent managers.
You can use the token WAIT with value Y ( WAIT=Y ) if you want to use CONCSUB to issue a concurrent request from within a shell script containing a sequence of steps. Using the token WAIT insures the managers deactivate, abort, or verify status before the shell script proceeds to the next step.
See: Controlling the Internal Concurrent Manager from the Operating System
Shell script customized for specific operating system starts.
CONCSUB username/password SYSADMIN 'System Administrator' SYSADMIN WAIT=Y CONCURRENT FND DEACTIVATE
When the shell script passes control to CONCSUB, CONCSUB waits until the program DEACTIVATE is complete before it returns control to the shell script.
Script issues the command to shut down the database.
Script issues the command to backup the database.
Script issues the command to startup the database.
$ startmgr sysmgr="apps/fnd" mgrname="std" printer="hqseq1" mailto="jsmith" restart="N" logfile="mgrlog" sleep="90" pmon="5" quesiz="10"
The shell script passes control to STARTMGR, which starts up the Internal manager (and all the other managers).
Shell script completes.
If the username/password are still supplied, the CONCSUB utility will work as usual.
If username only is supplied (no '/password' in the first argument), it will prompt you for an Oracle E-Business Suite username and password.
In the following example, CONCSUB would connect using the .dbc file, and then only run if the Oracle E-Business Suite user "sysadmin" with password "sysadmin" is successfully authenticated.
CONCSUB Apps:User SYSADMIN 'System Administrator' SYSADMIN/sysadmin CONCURRENT FND VERIFY
The user can put the password in a file, and then redirect it to standard input (stdin). In UNIX the command would be executed as follows:
CONCSUB Apps:User SYSADMIN 'System Administrator' SYSADMIN CONCURRENT FND FNDMNRMT Y 0 20221 < password.file
where password.file is an ASCII file that contains the password. This method is recommended for use in shell scripts or batch processes.
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:
This table contains a complete history of all concurrent 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.
This table records arguments passed by the concurrent manager to each program it starts running.
This table records when requests do not update database tables.
This table records information about Oracle E-Business Suite and operating system processes.
This table collects runtime performance statistics for concurrent requests.
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.
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 E-Business Suite log files and output files.
Tip: 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 E-Business Suite.
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.
When you purge concurrent request information, you lose audit details. The Signon Audit Concurrent Requests report uses this audit information.
This section describes how to manage parallel concurrent processing.
Parallel concurrent processing is always active when Generic Service Management (GSM) is active. Parallel concurrent processing can no longer be activated independently of Generic Service Management.
However, automatic activation of PCP does not additionally require that primary nodes be assigned for all concurrent managers and other GSM-managed services. If no primary node is assigned for a service instance, the Internal Concurrent Manager (ICM) assigns a valid concurrent processing server node as the target node. In general, this node will be the same node where the Internal Concurrent Manager is running. In the case where the ICM is not on a concurrent processing server node, the ICM chooses an active concurrent processing server node in the system. If no concurrent processing server node is available, no target node will be assigned.
Note that if a concurrent manager does have an assigned primary node, it will only try to start up on that node; if the primary node is down, it will look for its assigned secondary node, if one exists. If both the primary and secondary nodes are unavailable, the concurrent manager will not start (the ICM will not look for another node on which to start the concurrent manager). This strategy prevents overloading any node in the case of failover.
The concurrent managers are aware of many aspects of the system state when they start up. When an ICM successfully starts up it checks the TNS listeners and database instances on all remote nodes and if an instance is down, the affected managers and services switch to their secondary nodes. Processes managed under GSM will only start on nodes that are in Online mode. If a node is changed from Online to Offline, the processes on that node will be shut down and switch to a secondary node if possible.
Concurrent processing provides database instance-sensitive failover capabilities. When an instance is down, all managers connecting to it switch to a secondary middle-tier node.
However, if you prefer to handle instance failover separately from such middle-tier failover (for example, using TNS connection-time failover mechanism instead), use the profile option Concurrent:PCP Instance Check. When this profile option is set to OFF, Parallel Concurrent Processing will not provide database instance failover support; however, it will continue to provide middle-tier node failover support when a node goes down.
You define concurrent managers either in the Create New Request Processing Manager page in Oracle Applications Manager or in the Concurrent Managers form. When you define a manager, you specify the manager type, which may be either Concurrent Manager, Internal Monitor, or Transaction Manager.
There are three other types of managers that Oracle E-Business Suite predefines for you: the Internal Concurrent Manager, which describes the Internal Concurrent Manager process, the Conflict Resolution Manager, and the Scheduler. For the Conflict Resolution Manager and Scheduler you can assign the primary and secondary nodes. For the Internal Concurrent Manager you assign the primary node only.
To each concurrent manager and each Internal Monitor Process, you may assign a primary and a secondary node. You may also assign primary and secondary system queue names, if a platform-specific queue management system is available on your platform. See: Concurrent Managers, Oracle E-Business Suite System Administrator's Guide - Configuration.
Using the Services Instances page in Oracle Applications Manager (OAM) or the Administer Concurrent Managers form, you can view the target node for each concurrent manager in a parallel concurrent processing environment. The target node is the node on which the processes associated with a concurrent manager should run. It can be the node that is explicitly defined as the concurrent manager's primary node in the Concurrent Managers window or the node assigned by the Internal Concurrent Manager.
If you have defined primary and secondary nodes for a manager, then when its primary node and ORACLE instance are available, the target node is set to the primary node. Otherwise, the target node is set to the manager's secondary node (if that node and its ORACLE instance are available). During process migration, processes migrate from their current node to the target node.
Using the Services Instances page in Oracle Applications Manager or the Administer Concurrent Managers form, you can start, stop, abort, restart, and monitor concurrent managers and Internal Monitor Processes running on multiple nodes from any node in your parallel concurrent processing environment. You do not need to log onto a node to control concurrent processing on it. You can also terminate the Internal Concurrent Manager or any other concurrent manager from any node in your parallel concurrent processing environment.
In an environment enabled with parallel concurrent processing, primary node assignment is optional for the Internal Concurrent Manager. The Internal Concurrent Manager can be started from any of the nodes (host machines) identified as concurrent processing server enabled. In the absence of a primary node assignment for the Internal Concurrent Manager, the Internal Concurrent Manager will stay on the node (host machine) where it was started. If a primary node is assigned, the Internal Concurrent Manager will migrate to that node if it was started on a different node.
If the node on which the Internal Concurrent Manager is currently running becomes unavailable or the database instance to which it is connected to becomes unavailable, the Internal Concurrent Manager will be restarted on a alternate concurrent processing node. If no primary node is assigned, the Internal Concurrent Manager will continue to operate on the node on which it was restarted. If a primary node has been assigned to the Internal Concurrent Manager, then it will be migrated back to that node whenever both the node and the instance to which the Internal Concurrent Manager connects to from that node becomes available
You start up parallel concurrent processing as you would ordinary concurrent processing, by running the adcmctl.sh script from the operating system prompt.
The Internal Concurrent Manager starts up on the node on which you run the adcmctl.sh script. If it has a different assigned node, it will migrate to that node if available.
After the Internal Concurrent Manager starts up, it starts all the Internal Monitor Processes and all the concurrent managers. It attempts to start Internal Monitor Processes and concurrent managers on their primary nodes, and resorts to a secondary node only if a primary node is unavailable.
You shut down parallel concurrent processing by issuing a "Stop" command in the OAM Service Instances page or a "Deactivate" command in the Administer Concurrent Managers form. All concurrent managers and Internal Monitor processes are shut down before the Internal Concurrent Manager shuts down.
You can terminate running concurrent processes for a concurrent manager on the local node or on remote nodes by issuing an "Abort" command from the OAM Service Instances page or a "Terminate" command from the Administer Concurrent Managers form.
Most process migration occurs automatically in response to the failure or subsequent availability of a primary node. However, you may migrate processes manually by changing the node assignments for a concurrent manager or Internal Monitor Process using the Concurrent Managers form. To put your changes into effect, issue a "Verify" command against the Internal Concurrent Manager from the Administer Concurrent Managers form.
Related Topics
Concurrent Managers, Oracle E-Business Suite System Administrator's Guide - Configuration
This essay explains the user profile option settings relevant to submitting concurrent requests.
End users can control certain runtime options for their concurrent requests. For example, you can choose a specific date on which to start a request.
If a user does not explicitly enter these options at the time of the request, concurrent processing options default to their user profile values.
As System Administrator, you set user profile values for your end users with the System Profile Values window. Both you and your end users can set some of your own profile values using the Personal Profile Values form.
You or your users can use the Requests window to change the concurrent processing options for a submitted request up until the time it starts running.
As System Administrator you can change all concurrent options for any request.
Your users can change most of their request's concurrent options.
End users cannot change (nor set) the priority of their request, or the report access level for viewing request log files and report output files online.
The following table lists the concurrent processing user profile options and an explanation of each:
User Profile Option | Explanation |
---|---|
Concurrent: Hold Requests | "Yes" places concurrent requests on hold. "No" starts programs according to the request's priority and start time. |
Concurrent: Multiple Time Zones | "Yes" ensures that requests are scheduled immediately regardless of the time zone your client is running in. |
Concurrent: Report Access Level | Viewing a request's output/log files online and reprinting reports can be accessed according to: "Responsibility" - by anyone using the responsibility that submitted the request "User" - by only the user who submitted the request. |
Concurrent: Report Copies | The number of output copies that print for each report. |
Concurrent: Request Priority | Requests normally run according to start time, on a "first-submitted, first-run" basis. Priority overrides request start time. A higher priority request starts before an earlier request. Priorities range from 1 (highest) to 99 (lowest). The standard default is 50. |
Concurrent: Request Start Time | The date and time requests are available to start running. If the start date and time is at or before the current date and time, requests may be run immediately. |
Concurrent: Save Output | "Yes" saves concurrent program outputs in a standard file format. Some concurrent programs do not generate an output file. |
Concurrent: Sequential Requests | "Yes" forces requests to run one at a time (sequentially) according to the requests' start dates and times. "No" means requests can run concurrently when their concurrent programs are compatible. |
Concurrent: Wait for Available TM | You can specify the maximum number of seconds that the client will wait for a given transaction manager (TM) to become available before moving on to try a different TM. |
Concurrent: URL Lifetime | This profile option determines the length of time in minutes a URL for a request ouput is retained before it is deleted from the system. |
Printer | The printer which prints your reports. |
Most concurrent user profile options may be set by the System Administrator at all four levels: site, application, responsibility, and user. The user profile Concurrent:Report Access Level may not be set at the application level.
Your users can change the default values for most of the concurrent processing profile options. However, they cannot set Concurrent: Request Priority, or Concurrent: Report Access Level.
Related Topics
Overview of Concurrent Processing
This section describes reports used in managing concurrent programs and reports. The following topics are covered in this chapter:
Request Sets Report
Report Group Responsibilities Report
Concurrent Program Details Report
Concurrent Programs Report
This report documents request set definitions, including the set's owner, program incompatibilities, as well as printer and print style information. Use this report when defining or editing request set definitions.
None.
The report headings provide you with general information about the contents of the report.
Related Topics
Overview of Concurrent Programs and Requests, Oracle E-Business Suite System Administrator's Guide - Configuration
Organizing Programs into Request Sets, Oracle E-Business Suite System Administrator's Guide - Configuration
This report lists those responsibilities which have access to a report or a request set. Use this report when granting access privileges to reports and request sets, either by assigning reports and request sets to request security groups, or when assigning owners to a request set.
Choose the application name associated with the report or request set.
Either choose the name of a report or request set.
Related Topics
Overview of Concurrent Programs and Requests, Oracle E-Business Suite System Administrator's Guide - Configuration
Organizing Programs into Request Groups, Oracle E-Business Suite System Administrator's Guide - Configuration
Request Groups, Oracle E-Business Suite System Administrator's Guide - Configuration
This report documents concurrent program definitions, including executable file information, execution method, incompatible program listings, and program parameters. If a concurrent program generates a report, column and row information, as well as print output and print style, are also documented.
Use this report when considering concurrent program modifications, such as modifying program incompatibility rules.
Caution: If you do not enter any parameters, the report returns values for all concurrent programs, and may be very lengthy.
Choose the application name associated with the concurrent program whose program definition details you wish to report on.
Choose only an application name, without a program name, if you wish to run a program definition details report on all concurrent programs associated with an application.
Choose the name of a concurrent program whose program definition details you wish to report on. You must enter a value for Application Name before entering a value for Program.
The report headings display the specified report parameters and provide you with general information about the contents of the report.
This report shows which concurrent programs are currently enabled nand which programs are disabled.
Use this report to record the execution method, argument method, run alone status, standard submission status, request type, and print style information associated with your concurrent programs.
Choose the application name associated with the concurrent programs whose program information you wish to report on.
If you do not enter an application name, the report will return values for all concurrent programs.
The report headings display the specified report parameters and provide you with general information about the contents of the report.
Related Topics
Overview of Concurrent Programs and Requests, Oracle E-Business Suite System Administrator's Guide - Configuration
Concurrent Program Details Report
Concurrent Programs, Oracle E-Business Suite System Administrator's Guide - Configuration
request log files, concurrent manager log files, and report output files from your product directories maintained by the operating system
records (rows) from Application Object Library database tables that contain history information about concurrent requests and concurrent manager processes.
Use this program to compute performance statistics for each of the concurrent programs, if the Concurrent: Collect Request Statistics profile option is set to "Yes".
Variable | Description |
---|---|
All | Purges records from database tables that record history information for concurrent requests, history information for concurrent managers, and purges request log files, manager log files, and report output files from the operating system. |
Manager | Purges records from database tables that record history information for concurrent managers, and purges manager log files from the operating system. |
Request | Purges records from database tables that record history information for concurrent requests, and purges request log files and report output files from the operating system. |
Variable | Description |
---|---|
Age | Enter the number of days for which you want to save concurrent request history, log files, and report output files. The purge program deletes all records older (in days) than the number you enter. For example, if you enter "5", then all concurrent request history, log files, and report output files older than five days is purged. |
Count | Enter the number of (most recent) records for which you want to save concurrent request history, log file, and report output files. The purge program starts from the most recent records, retains the number you enter, and purges all remaining records. For example, if you enter "5", then the five most recent concurrent request history records, request log files, manager log files, report output files are saved, and all remaining records are purged. |
Enter a value to define the number of days for Mode=Age or the number of records for Mode=Count. The valid values are 1 - 9999999.
Enter the Oracle ID that concurrent programs connect to for which you want to purge concurrent request records, and associated log files and report output files. Oracle ID has relevance when the Entity is either "Request" or "All".
For example, if you enter AP1, then the program purges all request records, log files, and report output files associated with requests to run programs that connect to the AP1 Oracle ID.
Enter the application username whose concurrent request records and associated log files and report output files you wish to purge. Username has relevance when the Entity is either "Request" or "All".
For example, if you enter JSMITH, then the program purges all request records, log files, and report output files associated with requests submitted by user JSMITH.
Select the application associated with the responsibility for which you want to purge concurrent request records, and associated log files and report output files. Responsibility Application is used with the Responsibility option, and has relevance when the Entity is either "Request" or "All".
Select the responsibility for which you want to purge concurrent request records, and associated log files and report output files. Responsibility has relevance when the Entity is either "Request" or "All".
For example, if you select the System Administrator responsibility, then the program purges all request records, log files, and report output files associated with requests submitted by users operating under the System Administrator responsibility.
Select the application for which you want to purge concurrent request records, and associated log files and report output files. Program Application has relevance when the Entity is either "Request" or "All".
For example, if you select Oracle Payables, then the program purges all request records, log files, and report output files associated with requests to run Oracle Payables programs.
Select the program for which you want to purge concurrent request records, and associated log files and report output files. Program has relevance when the Entity is either "Request" or "All".
For example, if you select Program X, then the purge program purges all request records, log files, and report output files associated with requests to run Program X.
Select the application associated with the concurrent manager for which you want to purge concurrent request records, and associated log files and report output files.
Manager Application is used with the Manager option, and has different effects when Entity is set to "Request, and when Entity is set to "Manager" or "All".
When Entity is set to "Request", the program purges all request records, log files, and report output files associated with requests run by the concurrent manager named in the Manager option.
When Entity is set to either "Manager" or "All", in addition to the above, the program also purges all manager log files associated with the concurrent manager named in the Manager option.
Select the concurrent manager for which you want to purge concurrent request records, and associated log files and report output files.
Manager is used with the Manager Application option, and has different effects when Entity is set to "Request," and when Entity is set to "Manager" or "All".
When Entity is set to "Request", the program purges all request records, log files, and report output files associated with requests run by the concurrent manager named in the Manager option.
When Entity is set to either "Manager" or "All", in addition to the above, the program also purges all manager log files associated with the concurrent manager named in the Manager option.
Select whether you want a report listing the number of records purged by the Purge Concurrent Request and/or Manager Data program.
Variable | Description |
---|---|
No | Run the program but do not generate a report. |
Yes | Run the program and generate a report. |
Select whether you want to delete records from the FND_DUAL table.
Variable | Description |
---|---|
No | .Do not delete records from FND_DUAL. |
Yes | Delete records from FND_DUAL. |
Related Topics
Overview of Concurrent Processing
Life cycle of a concurrent request
Reviewing Requests, Request Log Files, and Report Output Files