When you modify the Printer Driver you have to restart the Manager which runs the request which is attached to that Printer Driver, however,if you do not know which manager then you have to restart the Internal manager because the printer driver can be used by multiple managers and multiple requests.  If only a concurrent program definition is modified, running a verify on the Internal Manager will pick up the changes without the need for bouncing the manager.

Does the Internal manager schedule requests to be run or does it put requests into queues to be run by other managers?

This is a very common misconception. The ICM really does not have any such scheduling responsibilities. It has NOTHING to do with scheduling  requests, or deciding which manager will run a particular request.  Its function is only to run 'queue control' requests, which are requests to startup or shutdown other managers. It is responsible for startup and shutdown of the whole concurrent processing facility, and it also monitors the other managers periodically, and restarts them if they should go down. It can also take over the Conflict Resolution manager's job, and resolve incompatibilities.
If the ICM itself should go down, requests will continue to run normally, except for 'queue control' requests. You can restart it with 'startmgr', you do not need to kill the other managers first.

 
How can I check to see if a concurrent manager is running?

One way to see if a manager is running is to use the 'Administer Concurrent Managers' form. Navigate to Concurrent->Managers->Administer.
You will see two columns labeled 'Actual' and 'Target'. The Target column lists the number of processes that should be running for each manager for this particular workshift. The Actual column lists the number of processes that are actually running. If the Actual column is zero, there are no processes running for this manager. If the Target column is zero, then either a workshift has not been assigned to this manager, or the current workshift does not specify any target processes. If the target column is not zero, then the manager processes have either failed to start up, or gone down. You should check the manager's logfile and the ICM logfile. You can also search for OS processes using the 'ps' command. It is possible for the form to be inaccurate, i.e. it may show actual processes even though they are not really running. When in doubt, check for processes at the OS level. On NT, you can check to see if the Concurrent Manager service is running using the Services control panel.

Where do concurrent request or manager logfiles and output files go?

The concurrent manager first looks for the environment variable $APPLCSF. If this is set, it creates a path using two other environment variables: $APPLLOG and $APPLOUT
It places log files in $APPLCSF/$APPLLOG, output files go in $APPLCSF/$APPLOUT

         So for example, if you have this environment set:
                 $APPLCSF = /u01/appl/common
                 $APPLLOG = log
                 $APPLOUT = out

The concurrent manager will place log files in /u01/appl/common/log, and output files in /u01/appl/common/out
Note that $APPLCSF must be a full, absolute path, and the other two are directory names.
If $APPLCSF is not set, it places the files under the product top of  the application associated with the request. For example, a PO report would go under $PO_TOP/$APPLLOG and $PO_TOP/$APPLOUT
         Logfiles go to:  /u01/appl/po/9.0/log
         Output files to: /u01/appl/po/9.0/out
         All these directories must exist and have the correct permissions.
Note that all concurrent requests produce a log file, but not necessarily an output file.

Concurrent manager logfiles follow the same convention, and will be found in the $APPLLOG directory

What are the logfile and output file naming conventions?
         Request logfiles: l.req
         Output files: If $APPCPNAM is not set:  .
                       If $APPCPNAM = REQID:     o.out
                       If $APPCPNAM = USER:      .out

Where:  = The request id of the concurrent request
And:  = The id of the user that submitted the request

Manager logfiles:      

         ICM logfile: Default is std.mgr, can be changed with the mgrname
         startup parameter
         Concurrent manager log:                w.mgr
         Transaction manager log:               t.mgr
         Conflict Resolution manager log:    c.mgr

Where:  is the concurrent process id of the manager


How do I clean out the Concurrent Manager tables?

Cleaning out the tables is a useful method of making sure that there are no invalid statuses that can prevent the managers from starting. Previously, this has been done by truncating fnd_concurrent_processes and/or fnd_concurrent_requests. Truncation of the tables is a little drastic, and can cause problems later when trying to purge requests, not to mention losing all of the request information.

Run the script, cmclean.sql, article note 134007.1 CMCLEAN.SQL - Non Destructive Script to Clean Concurrent Manager Tables It will make sure the relevant status codes are valid without deleting any information.      

How do I tell concurrent manager processes apart at the OS level?
         Use: pf -ef | grep FNDLIBR
      
         Other managers will have the name of the executable, like ARLIBR or  INVLIBR:

         $ ps -ef | grep ARLIBR

         The Conflict Resolution manager will look like:

         $ ps -ef | grep FNDCRM

 I hit the Restart button to start the Standard manager, but it still did not start?

Telling a manager to restart just sets the status to Restart. The ICM will start it the next process monitor session or the next time the ICM starts. Use Activate to start a manager immediately. When a manager is deactivated manually, the ICM will not restart it, you will need to set it to Restart, or activate it manually.


How many rows are in FND_CONCURRENT_REQUESTS and FND_CONCURRENT_PROCESSES  tables?

Depending on the specification of the system it has been seen that when tables reach above 3000-4000 rows, the performance begins to diminish, however, there could be 30000-40000 rows in the tale before the performance begins to degrade.  You may want to run the Purge Concurrent Request and/or Manager Data on a regular basis, dependant on the amount of requests being run.

         The Purge Concurrent Requests job can be used to purge:
         Requests, Mgr logs, and All requests depending on what is chosen.

         Use the following options: Enter = All, Mode = AGE, Mode Value = 15

         The std.mgr log continuously grows where it may good to archive it regularly.

Any processes pending in Internal or Conflict Resolution Manager?

Best course of action before starting the Concurrent Managers is to cancel any "Deactivate" or "Verify" jobs pending in the Internal Manager and place any other pending jobs on hold.

How do I turn on transaction manager diagnostics?

Set the profile option 'Concurrent:Debug Flags' to 'TCTM1' at the site level. This will cause transactions to make debug entries in the  FND_CONCURRENT_DEBUG_INFO table. Truncate this table before running a tranasction, then select the entries from the table.
Starting the managers with diag=Y will also produce more information in the transaction manager logfile.

How do transaction managers work?
         Briefly:

1. A tranasction manager is started on the concurrent processing server, and periodically reads the pipe for incoming transactions.
2. A client program (usually a form) calls the FND_TRANSACTION.SYNCHRONOUS function. 
3. This function writes a message into the pipe containing the program to be run and its parameters.
4. FND_TRANSACTION.SYNCHRONOUS begins reading a return pipe for the return status.
5. The manager sees the message in the pipe, retrieves the program id and parameters.
6. The manager runs the program with the specified parameters. The program will be of type 'Immediate', so there will not be a separate concurrent request run.
7. The program completes, and the manager packs its return status into the return pipe.
8. FND_TRANSACTION.SYNCHRONOUS reads the return value and passes it back to its caller.

Note that these events take place essentially simultaneously on the client and server. This is a synchronous transaction because the client waits for the server to return, or times out waiting for it.
  
Problem....

   When you try to submit a request like Active users or Active responsibilities, request gets submitted.
   When we view the help requests, you find that it is inactive / nomanager.
   Within 12 to 15 seconds, you refresh-it gets completed.

Initially, you could find only inactive and we look at the diagnostic- the concurrent manager assigned is not picking up.

There is no specialization rules in any managers except the include program this source.
Solution....

Most often when this occurs where a request goes  "inactive/no manager" and is then processed a short time later, the solution is to either increase the cache size  for your Standard manger, or increase the actual number of Standard manager processes.

Cache Size is set on the CONCURRENT/MANAGER/DEFINE form.  Basically, this regulates how many requests a manager will pick up for each sleep cycle.


How do I process more concurrent requests concurrently?

The Concurrent Manager parameters, (Query the concurrent manager by Login as Sysadmin, navigate -> Concurrent -> Manager -> Define and Query for   the relevant concurrent manager), should be modified to handle more concurrent requests concurrently, this can be done in two steps:

(i) Increase the Number of Target processes for the manager
(ii) Change the cache size of the concurrent manager  as this determines how many requests will be evaluated by a manager at a time and should match the target (process) value as set above.