Activate Concurrent Manager -- STARTMGR
Verify Concurrent Manager Status -- CONCSUB FND VERIFY
Deactivate Concurrent Manager -- CONCSUB FND DEACTIVATE
Terminate requests and deactivate manager -- CONCSUB FND ABORT

CONCSUB SYSADMIN ‘System Administartor’ SYSADMIN CONCURRENT FND DEACTIVATE

CONCSUB SYSADMIN ‘System Administartor’ SYSADMIN CONCURRENT FND ABORT

CONCSUB SYSADMIN ‘System Administartor’ SYSADMIN CONCURRENT FND VERIFY

Important to understand Oracle Applications utilities the CONCSUB utility.

CONCSUB is a program that allows you to submit concurrent requests from your operating system.The CONCSUB is a utility which allows you to submit a concurrent program to the concurrent manager from the operating system level without having to log on to Oracle Applications.
The CONCSUB executable is located at $FND_TOP/bin/CONCSUB.
The functionality of the CONCSUB can be categorized into the following
• Submitting Concurrent Requests
• Controlling Concurrent Managers

Submitting Concurrent Requests

You can use the CONCSUB to execute both seeded and custom programs in Oracle Applications. In case of custom programs they must first be registered in Oracle Applications before you can execute them with CONCSUB.
The following can be used in Oracle Applications to run the active users report from the command line without logging in the applications
CONCSUB APPS/APPS SYSADMIN "System Administrator" SYSADMIN WAIT=N CONCURRENT FND FNDSCURS PROGRAM_NAME='"Active Users"'
Submitted request 2866136 for CONCURRENT FND FNDSCURS PROGRAM_NAME="Active Users"
The log and out file for this program is also created at the location defined by your $APPLCSF/$APPLLOG and $APPLCSF/$APPLOUT respectively.

The WAIT=Y/N is used to specify weather to wait for the first concurrent request to be completed before the second is submitted or not.

You can also use various printing parameters with the COCNCSUB to directly print the output of your concurrent request.
PRINTER=
NUMBER_OF_COPIES=
PRINT_STYLE=
LANGUAGE=
Also you could specify the start date and completion options along with CONCSUB by using the following parameters
START=
REPEAT_DAYS=
REPEAT_END=
Syntax: CONCSUB [WAIT= [START=] [REPEAT_DAYS=] [REPEAT_END=]

Example: CONCSUB SCOTT/TIGER SYSADMIN 'System Administrator' SYSADMIN WAIT=Y CONCURRENT FND FNDMNRMT START='"01-JAN-2000 23:00:00"' REPEAT_DAYS=1 REPEAT_END='"01-JAN-2001 23:59:00"' Y 0 0

ORACLE ID: Username and password of the ORACLE ID for Applications, separated by a slash ("/").

Responsibility Application Short Name: Enter the short name of the application for your responsibility. This name, along with your responsibility name, will be used to select a responsibility for your concurrent request to run in.

Responsibility Name: This name, along with your responsibility application short name, will be used to select a responsibility for your concurrent request to run in.

User Name: Enter the name of your Application Object Library user. This name will be used to update the Who information for any data your concurrent program changes.

Controlling Concurrent Managers

Apart from submitting concurrent request the CONCSUB can also be used to shutdown your concurrent managers
CONCSUB apps/apps_password SYSADMIN 'System Administrator' SYSADMIN WAIT=N CONCURRENT FND SHUTDOWN
Sometimes the shutdown of the concurrent managers via the CONCSUB utility using the SHUTDOWN clause hangs and you may want to terminate your concurrent managers, in such a case you can use the ABORT clause with CONCSUB to do a force shutdown of your concurrent managers.
CONCSUB apps/apps SYSADMIN 'System Administrator' SYSADMIN WAIT=N CONCURRENT FND ABORT
In this case a concurrent request to terminate the concurrent managers is fired with a -75 priority. In case of the shutdown the priority is 0 and default priority is of a concurrent request 50, by assigning a -75 priority the CONCSUB ensures abort is executed before shutdown.
Needless to say that the shutdown would fail in case the SYSADMN user or the System Administrator responsibility is inactive.

However to start the concurrent managers the CONCSUB is not used instead the startmgr executable is used.(Though possible)
This is located at $FND_TOP/bin/startmgr.
$startmgr sysmgr=apps/apps@sam
Starting icm@sam Internal Concurrent Manager
Default printer is
By default if no manager name is specified the ICM or the Internal Concurrent Manager is started. You can also start a specific manager by using the mgrname clause
To use CONCSUB to start the concurrent managers the STARTUP clause is used
$ CONCSUB apps/apps SYSADMIN 'System Administrator' SYSADMIN WAIT=N CONCURRENT FND STARTUP
Submitted request 2849496 for CONCURRENT FND STARTUP

How to Restart The Concurrent Manager in Unix.

1. At the command line issue the following shutdown command:
CONCSUB apps/apps sysadmin 'System Administrator' SYSADMIN
CONCURRENT FND SHUTDOWN

Note: There are 3 options which can be used for controlling the Internal
Manager from the OS as follows:

SHUTDOWN = Standard, non-invasive shutdown.

DEACTIVATE = Will not allow further Requests to Process once Issued.

ABORT = Terminate Requests and Deactivate the Internal Manager.

2. At the command line, issue the following Start Up command:

startmgr sysmgr="[fnd_usernamd/fnd_password]" mgrname="[mgrname]" printer="[printername]"
mailto="[userid userid2...]" restart="[N|minutes]" logfile="[log_file_name]" sleep="
[new_check]" pmon="[manager_check]" quesiz="[number_check]" diag="[Y|N]"

Ex: startmgr sysmgr="applsys/apps" mgrname="std" printer="localprint"
mailto="jdoe jsmith" restart="N" logfile="mgrlog" sleep="90"
pmon="5" quesiz="10" diag="N"

Note: a space is required between arguments and the "diag" parameter
may be omitted if desired.

posted by Jaswinder Singh @ 3:22 AM

1 Comments:

At Wednesday, January 27, 2010, Anonymous said…

Hi Jaswinder,

You specify the abort option as terminate requests and deactivate the internal Manager. I have found that if you abort the concurrent managers while it has got running requests and do a full system shutdown due to forced maintenance ect and you start the environment again your concurrent requests that were in a running state will kick off again and run to completion normally.

Any thoughts on how this is achieved?