Verify a Manager s Status

---

Verify a Manager's Status

Controlling Internal Manager

You can control the Internal Manager from the command line of the OS by using the STARTMGR command (or the net start command or Control Panel Services in Windows NT or Windows 2000) to start it or through the CONCSUB command to deactivate, verify, or abort it (net stop or Control Panel Services on Windows NT or Windows 2000). The utility can only be run on the server on which the Concurrent Managers are running, but can be called on that server from any other server on the same network.

STARTMGR

STARTMGR starts the ICM, which in turn starts all Concurrent Managers defined that should be running for that work shift. To successfully run this command, you have to be logged into the server with a user ID that has write privileges to the log directory and the out directory of every application, otherwise, the Concurrent Manager will be unable to write some or all of its files. STARTMGR has to be run anytime you have shutdown the Concurrent Managers, after the server has been rebooted, or after the database has been restarted. The STARTMGR command can take up to 10 optional parameters (listed with their description and default values in Table 12.8), passed into the command in any order with all but printers having a default value. For example:

 $ startmgr sysmgr=" apps/apps" mgrname='std" printer="lpr_finance" mailto="jdoe" restart=" N" logfile="mymanagerlog" queuesize="15" pmon="10" sleep="60" 

Table 12.8: STARTMGR Command with 10 Optional Parameters

Parameter	Description	Default
Sysmgr	Apps schema user ID and password.	Apps/apps
Mgrname	Name of the ICM (used for locking purposes).	STD
Printer	Default printer to which you want output sent.	No default
mailto	List of usernames who need to be informed whenever the ICM terminates.	Applmgr
Restart	Should the manager restart after a crash? Valid values are N (for no) or the number of seconds that it should wait to restart after abnormal stop.	N
Logfile	User specified file to use for the manager's own log file (not to be confused by the logs for the requests).	Std.mgr
Sleep	Number of seconds for the ICM to wait between checking for new requests in the FND_CONCURRENT_REQUESTS table.	60
PMon	Number of sleep cycles that the ICM or the CRM will wait before checking for failed managers. This can be set lower than the default as the PMon resources that are dedicated to this process does not require such a long sleep interval.	20
Quesiz	Number of PMon iterations that the Internal Concurent Manager will wait while scanning for sudden changes in the number of actively running Concurrent Manager workers.	1
Diag	Diagnostic output to be produced to aid in debugging. The default (N) provides better performance. Can also be set to Y.	N

These commands start the ICM, which in turn starts up the CRM and the Scheduler Manager, followed by any specialized managers depending on their work shifts. FND_CONCURRENT_QUEUES and FND_CONCURRENT_QUEUE_SIZE provide information to the ICM about each manager, its work shift, and the target number of processes to be started (based on the value in the MAX_PROCESSES column of the FND_CONCURRENT_QUEUE table). If you want to verify that there is at least one Concurrent Manager process running on your server, you can check the Task Manager on Windows for a FNDLIBR process or ps -ef |grep FNDLIBR on a UNIX platform (ps -ef |grep FNDLIBR will work on Windows as well, thanks to the running of MKS Toolkit). FNDLIBR is the program library process that gets spawned when the ICM or any generic Standard Manager is running on your system. CRM program library process appears as FNDCRM.

Oracle Support will often have you check for the existence of FNDLIBR processes if it appears that your ICM did not start.

Once the managers are started on the system, ICM will insert one row into the FND_CONCURRENT_PROCESSES table for each running manager and one row for itself and will update the RUNNING_PROCESSES column in the FND_CONCURRENT_QUEUES table to reflect the actual number of running processes. When the actual number in the RUNNING_PROCESSES column matches the target number in the MAX_PROCESSES column, all managers that are scheduled for the current work shift are running. Each entry in the FND_CONCURRENT_PROCESSES table identifies the process ID (PID) of the OS process as well as the process's status code.

CONCSUB

CONCSUB is a utility for allowing the sysadmin username and password to have the ability to submit concurrent requests at the OS level. This utility, unlike many of the Applications utilities, is not menu driven. It runs from the command line, submits a concurrent request, and returns you to the command prompt once the concurrent request completes. You can check the status of your concurrent request via the Concurrent Request form.

The CONCSUB command takes the following form:

 CONCSUB applsys/pwd  'responsibility  application shortname' 'responsibility name' 'username' [wait=] CONCURRENT 'Program  application shortname'  PROGRAM 

Table 12.9 defines the parameters and their meaning.

Table 12.9: CONCSUB Parameters and Their Meanings

Parameter	Meaning
Applsys/pwd	Oracle application username and password that connects to Applications Object Library.
Responsibility Application Short Name	Application shortname of the responsibility you want to run the request for.
Responsibility Name	Name of the responsibility for which you want to run the request.
Username	Username of the person who is submitting the request.
Wait	Do you want CONCSUB to wait before returning the OS command prompt? N (default value) waits until the job completes. Y returns you to the command prompt. "n" is the number of seconds to wait before it exits. If this parameter is used, it has to come before concurrent.
Program Application Short Name	Short name of the program (for deactivate, abort, and verify, the program application shortname is FND).
PROGRAM	The program to submit (e.g., DEACTIVATE, VERIFY, ABORT).

Example of a CONCSUB command:

 Concsub applsys/apps SYSADMIN 'system Administraor' SYSADMIN  concurrent fnd deactivate 

You can use CONCSUB to shutdown Concurrent Managers before the sysadmin reboots the server, before the database administrator shuts down the database, or when you need changes to Concurrent Managers to take effect.

---