Run the following sql script to check the concurrent manager status.

Run the following sql script to check the concurrent manager status.
$ cd $FND_TOP/sql
$ sqlplus -s apps/apps @afimchk.sql


. $ADMIN_SCRIPTS_HOME/adcmctl.sh

ps -ef | grep FNDLIBR | grep appmgr01      

Test the zip archives before staging

Execute the below in the location where u have the zip files for r12

for file in `ls *.zip`

do

  echo "Begin : $file " >> /tmp/valid.txt

  unzip -t $file            >>  /tmp/valid.txt

   echo "End : $file "  >> /tmp/valid.txt

done

After that once the script execution completes ..  check in /tmp/valid.txt

Also send me the o/p of

uname -a

df -H

clone at glance

Cloning Oracle Applications Release 12 with Rapid Clone [ID 406982.1]


Check all pre- requisits........

1. Apply Latest AD mini pack  (  run autoconfig in db tier as well as appsTier after every patching)
(

Create $ORACLE_HOME/appsutil/admin on the database tier.

  2. Copy adgrants.sql (UNIX) from this patch directory to $ORACLE_HOME/appsutil/admin. 

  3. Set the environment variable

  4. Use SQL*Plus to run the script:

     UNIX:

     $ sqlplus /nolog

     SQL> @$ORACLE_HOME/appsutil/admin/adgrants.sql <APPS schema name>)

then apply patch :-  adadmin -> change to maintenance mode



unzip patch as applmgr user and enter into the folder



give the command:-   adpatch apply=y

(Location of autocfg.sh in dbTier is   $ORACLE_HOME/appsutil/scripts/<Context_name>/
in appsTier $ADMIN_SCRIPTS_HOME)

2. Apply Latest Autoconfig Template patch( May take much time)
3. Apply all the latest patches for Rapid clone tool

4. then run as oracle user

$ cd [RDBMS ORACLE_HOME]/appsutil/scripts/[CONTEXT_NAME]
$ perl adpreclone.pl dbTier

5.run as applmgr user

$ cd [INST_TOP]/admin/scripts
$ perl adpreclone.pl appsTier

6.Stop Database as well as application

7.copy apps,db,inst from source to target system (copy "db" as oracle user and other as applmgr user)  before copying create users oracle and applmgr in target system. configure the pre- requests in target system.

8. after copying  run as oracle user in target system in dbTier

$ cd [RDBMS ORACLE_HOME]/appsutil/clone/bin
$ perl adcfgclone.pl dbTier

9. run as applmgr user in target system  in appsTier

$ cd [COMMON_TOP]/clone/bin
$ perl adcfgclone.pl appsTier


(While running above commands, it will ask some paths and config  ... provide according to your target system settings)
After this check the lisner.ora and tnsnames.ora   and set manually if any modification needed.

(cd $TNS_ADMIN   here you can find these files.

cd $ORACLE_HOME/network/admin/<context_name>/   (here also you can find these files..))


Bounce entire system (both dbTier and appsTier).

Change profile, Concurrent manager setting , printer setting etc. in application front end if any custom setting is there.

12c check

#!/bin/bash
#
# This script is supplied as is and is just
# an example of a script that could be used to gather
# data prior to an install.
#
# Script to check Linux enviroment
#
#
# Author:- Sharan
#
#
clear
echo "============================================"
echo "Script to check Linux enviroment"
echo "============================================"
echo
echo "---------------------------------------------------"
echo "From /etc/redhat-release:-"
echo "---------------------------------------------------"
cat /etc/redhat-release 2>&1
echo "---------------------------------------------------"
echo
echo "---------------------------------------------------"
echo "Query package version"
echo "---------------------------------------------------"
rpm -qa --queryformat "%{NAME}-%{VERSION}-%{RELEASE}(%{ARCH})\n"| grep make
rpm -qa --queryformat "%{NAME}-%{VERSION}-%{RELEASE}(%{ARCH})\n"| grep binutils
rpm -qa --queryformat "%{NAME}-%{VERSION}-%{RELEASE}(%{ARCH})\n"| grep gcc
rpm -qa --queryformat "%{NAME}-%{VERSION}-%{RELEASE}(%{ARCH})\n"| grep libaio
rpm -qa --queryformat "%{NAME}-%{VERSION}-%{RELEASE}(%{ARCH})\n"| grep glibc-common
rpm -qa --queryformat "%{NAME}-%{VERSION}-%{RELEASE}(%{ARCH})\n"| grep libstdc++
rpm -qa --queryformat "%{NAME}-%{VERSION}-%{RELEASE}(%{ARCH})\n"| grep setarch
rpm -qa --queryformat "%{NAME}-%{VERSION}-%{RELEASE}(%{ARCH})\n"| grep sysstat
rpm -qa --queryformat "%{NAME}-%{VERSION}-%{RELEASE}(%{ARCH})\n"| grep rng-utils
rpm -qa --queryformat "%{NAME}-%{VERSION}-%{RELEASE}(%{ARCH})\n"| grep libXtst
echo
echo "---------------------------------------------------"
echo "From /etc/passwd:-"
echo "---------------------------------------------------"
grep oemusr /etc/passwd 2>&1
echo "---------------------------------------------------"
echo
echo "---------------------------------------------------"
echo "From /etc/group:-"
echo "---------------------------------------------------"
grep oinstall /etc/group 2>&1
echo "---------------------------------------------------"
echo
echo "---------------------------------------------------"
echo "From Group:-"
echo "---------------------------------------------------"
groups oemusr 2>&1
echo "---------------------------------------------------"
echo " THE END"
echo "---------------------------------------------------"  

cm

Controlling Concurrent Managers

This essay explains how to control your concurrent managers.

Manager States

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 Applications 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.

The Internal Concurrent Manager activates and deactivates individual managers and enforces run-alone program and program incompatibility rules. See: Controlling Managers.

Starting Individual Managers

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 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

Deactivating Individual Managers

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 Applications 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).

Attention: 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.

Controlling the Internal Concurrent Manager

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.

Verify Concurrent Manager Status

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.

Controlling Managers from the Administer Managers form

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.

Controlling Managers

Manager	Control Function	Description
Internal Manager	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.
Any Other Manager	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".
Table 1 - 19. (Page 2 of 2)

Overview of Parallel Concurrent Processing

This essay explains what parallel concurrent processing is, describes the environments it runs in, and explains how it works.

What is Parallel Concurrent Processing?

Parallel concurrent processing allows you to distribute concurrent managers across multiple nodes in a cluster, massively parallel, or homogeneous networked environment. Instead of operating concurrent processing on a single node while other nodes are idle, you can spread concurrent processing across all available nodes, fully utilizing hardware resources.

Benefits of Parallel Concurrent Processing

Parallel concurrent processing provides Oracle Applications users with the following benefits:

• High performance--the ability to run concurrent processes on multiple nodes to improve concurrent processing throughput.

• Fault Tolerance--the ability to continue running concurrent processes on available nodes even when one or more nodes fails.

• Adaptability--the ability to integrate with platform-specific batch queue and load-balancing systems to maximize concurrent processing performance on a particular platform.

• Single Point of Control--the ability to administer concurrent managers running on multiple nodes from any node in a cluster, massively parallel, or homogeneous networked environment.

Parallel Concurrent Processing Environments

Parallel concurrent processing runs in multi-node environments, such as cluster, massively parallel, and homogeneous networked environments. In these environments, each node consists of one or more processors (CPUs) and their associated memory. Each node has its own memory that is not shared with other nodes And each node operates independently of other nodes, except when sharing a resource such as a disk.

With parallel concurrent processing, one or more concurrent managers run on one or more nodes in a multi-node environment. You decide where concurrent managers run when configuring your system.

You can define any set of concurrent manager specialization rules, and apply them across nodes in any way desired. For example, three "Oracle General Ledger" concurrent managers could be spread across three nodes. Or an "Oracle Payables" concurrent manager and an "Oracle General Ledger" concurrent manager could run simultaneously on the same node.

The following are examples of environments in which parallel concurrent processing can run:

Cluster Environments

In a cluster environment, multiple computers, each representing a single node, share a common pool of disks. Typical cluster environments include IBM HACMP, VAX Cluster, or a cluster of Sequent servers.

With parallel concurrent processing in a cluster environment, a single ORACLE database resides in the common disk pool, while multiple instances of Oracle Parallel Server run simultaneously on multiple nodes in the cluster. Multiple concurrent managers are also distributed across the nodes in the cluster.

Massively Parallel Environments

In a massively parallel environment, multiple nodes are housed in a single computer. All nodes share access to a common pool of disks. The IBM SP/2, for example, is a massively parallel computer.

With parallel concurrent processing in a massively parallel environment, separate Oracle Parallel Server instances run simultaneously on multiple nodes, with multiple concurrent managers also distributed across nodes.

Homogeneous Networked Environments

In homogeneous networked environments, multiple computers of the same type are connected via a local area network (LAN) to a single database server, or alternatively, to a cluster of database servers.

For example, a simple networked environment could consist of multiple Sun SPARCstations connected via a LAN to a single Sequent server. In a more complex networked environment, multiple Sun SPARCstations could connect to a cluster of Sequent servers.

With parallel concurrent processing in a homogeneous networked environment, concurrent managers run on multiple workstations. A single database server runs a single instance of ORACLE; or, a cluster of database servers runs multiple ORACLE instances using Oracle Parallel Server.

How Parallel Concurrent Processing Works

Concurrent Managers

With parallel concurrent processing, each node with concurrent managers may or may not be running an ORACLE instance. On a node that is not running ORACLE, the concurrent manager(s) connect via SQL*Net to a node that is running ORACLE.

To each concurrent manager, you assign a primary and a secondary node. Initially, a concurrent manager is started on its primary node. In case of node or ORACLE instance failure, a concurrent manager migrates to its secondary node.

A concurrent manager migrates back to its primary node once that node becomes available. During migration, the processes of a single concurrent manager may be spread across its primary and secondary nodes.

Internal Concurrent Manager

The Internal Concurrent Manager can run on any node, and can activate and deactivate concurrent managers on the same or other nodes. Since the Internal Concurrent Manager must be active at all times, it needs high fault tolerance. To provide this fault tolerance, parallel concurrent processing uses Internal Monitor Processes.

Internal Monitor Processes

The sole job of an Internal Monitor Process is to monitor the Internal Concurrent Manager and to restart that manager should it fail. The first Internal Monitor Process to detect that the Internal Concurrent Manager has failed restarts that manager on its own node.

Only one Internal Monitor Process can be active on a single node. You decide which nodes have an Internal Monitor Process when you configure your system. You can also assign each Internal Monitor Process a primary and a secondary node to ensure fail over protection.

Internal Monitor Processes, like concurrent managers, can have assigned work shifts, and are activated and deactivated by the Internal Concurrent Manager.

Log and Output File Access

The concurrent log and output files from requests that run on any node are accessible on-line from any other node. Users need not log onto a node to view the log and output files from requests run on that node. See: Database Instances, Manager Location, and File Distribution.

This capability relies on setup steps taken at install time. For more information, refer to the installation documentation for your platform.

Integration with Platform-Specific Queuing and Load-Balancing Systems

Some cluster or massively parallel systems have their own mechanisms for queuing batch processes or distributing process loads--for example, VMS batch queues or IBM LoadLeveler. Because users may wish to manage all processing, not just Oracle Applications processing, using these mechanisms, parallel concurrent processing is designed to integrate with them. Thus, you can match your concurrent process management to the specific capabilities of your operating platform.

For more information on integrating with platform-specific queuing and load-balancing systems, refer to the installation documentation for your platform.

Controlling the Internal Concurrent Manager from the Operating System

There are two 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.

Table 1 - 20 compares the Internal manager control states displayed by the Administer Concurrent Managers form with their corresponding operating system command. Not all arguments are shown.

Controlling the Internal Manager from the OS

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
Table 1 - 20. (Page 1 of 1)

Starting the Internal Concurrent Manager from the Operating System

To start the concurrent managers, you can invoke the STARTMGR command from your operating system prompt. This command starts the Internal Concurrent Manager, which in turn starts any concurrent managers you have defined.

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.

See: Oracle Applications Installation Guide for your operating system

Use the STARTMGR command:

• during installation of Oracle Applications

• after you shut down the concurrent managers

• after MIS restarts the operating system

• after the database administrator restarts the database

The STARTMGR command is platform-dependent, so refer to your Oracle Applications Installation Guide for the specific syntax to use.

See: Concurrent Managers - Appendix: System Reference Material, Oracle Applications Installation Guide for your operating system

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="applsys/fnd"  mgrname="std"

 printer="hqseq1"  mailto="jsmith"  restart="N"

 logfile="mgrlog"  sleep="90"  pmon="5"  quesiz="10"

Viewing the Internal Concurrent Manager startup parameters

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)                           

Shutting down the Internal Concurrent Manager from the Operating System

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 applsys/pwd 'Responsibility application shortname'

 'Responsibility name' 'Username' [WAIT={Y|N|n}] CONCURRENT

 'Program application shortname'  PROGRAM

Parameters

applsys/pwd	The ORACLE username and password that connects to Oracle Application Object Library data.
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.

Example Syntax using CONCSUB

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

Using CONCSUB to shut down your managers

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.

Example - nightly shutdown using CONCSUB

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

1. Shell script customized for specific operating system starts.

2. CONCSUB applsys/pwd 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.

3. Script issues the command to shut down the database.

4. Script issues the command to backup the database.

5. Script issues the command to startup the database.

6. $ startmgr sysmgr="applsys/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).

7. Shell script completes.

Hiding the password using CONCSUB

If username/password are still supplied, the CONCSUB utility will work as usual.

If username only is supplied (no '/pwd' in the first argument), it will prompt you for the password:

ORACLE Password:

The echo is turned off. For example, the command below does not include the ORACLE Password.

CONCSUB applsys SYSADMIN 'System Administrator' SYSADMIN

 CONCURRENT FND

FNDMNRMT Y 0 20221

ORACLE Password:

Submitted request 32157 for CONCURRENT FND FNDMNRMT Y 0 20221

Now, the first argument has to be the application username as usual (for example, SYSADMIN).

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 applsys 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.

Administer Concurrent Managers Window

View the status of your concurrent managers (including any transaction managers) and, if you wish, change the status of any manager by issuing a control command. For example, you can deactivate a manager that is currently active, then view its new status after the change takes effect.

Administer Concurrent Managers Block

Node

In a parallel concurrent processing environment, a manager's processes are targeted to run on this node.
If a concurrent manager is defined to use a platform-specific system queue, this field displays the name of the queue which the manager submits its processes to.
Processes Actual
Each manager process can run one concurrent request (start one concurrent program). Typically, the number of actual processes equals the number of target processes (the maximum number of requests a manager can run).
However, the number of actual processes may be less than the number of target processes due to lack of requests, manager deactivation, or manager migration.
Processes Target
This field displays the maximum number of manager processes that can be active for this manager.
Requests Running/Requests Pending
Typically, when there are requests pending, this number should be the same as the number of actual processes. However, if there are no pending requests, or requests were just submitted, the number of requests running may be less than the number of actual processes.
Moreover, if a concurrent program is incompatible with another program currently running, it does not start until the incompatible program has completed. In this case, the number of requests running may be less than number of actual processes even when there are requests pending.
Status
This field displays the status of a manager after you have chosen a specific action for it using the top row of buttons near the bottom of the window.
You can control concurrent managers individually or collectively by controlling the Internal Concurrent Manager. This field is blank when managers have been activated by the Internal Concurrent Manager.
In a parallel processing environment, this field displays Target node/queue unavailable when the primary and secondary nodes (or system queues) are not available.

Controlling a Specific Manager

The actions you can choose for controlling a manager are:

Terminate	When you terminate requests and deactivate the Internal Concurrent Manager, all running requests (running concurrent programs) are terminated, and all managers are deactivated.
	Managers previously deactivated on an individual basis are not affected.
	You can terminate requests and deactivate individual managers. All running requests (running concurrent programs) handled by the manager are terminated.
	Once deactivated, a manager does not restart until you select the manager and choose the Activate button.
Deactivate	When you deactivate the Internal Concurrent Manager, all other managers are deactivated as well. Managers previously deactivated on an individual basis are not affected.
	You can deactivate individual managers. Once deactivated, a manager does not restart until you select the manager and choose the Activate button.
	When you deactivate a manager, including the Internal Concurrent Manager, all requests (concurrent programs) currently running are allowed to complete before the manager(s) shut down.
Verify	This choice appears only when you select the Internal Concurrent Manager.
	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 button.
	Another result of selecting this choice is that the Internal Concurrent Manager rereads concurrent program incompatibility rules.
Restart	This choice appears only when you select an individual manager.
	When you restart a concurrent manager, the manager rereads its definition.
	You should restart a manager when you have made the following changes using the Define Concurrent Manager form, and you wish those changes to take effect:
	- Change work shift assignments
	- Modify the number of Target Processes
	- In a parallel concurrent processing environment, change node or system queue information
Activate	When you activate the Internal Concurrent Manager, you activate all other managers as well, except those managers that were deactivated on an individual basis.
	You cannot activate the Internal Concurrent Manager from the PC client. The Internal Concurrent Manager is only activated from the server.
	You can also activate an individual concurrent manager that is currently deactivated, so long as the Internal manager is active. If the manager is defined to work in the current work shift, then the Internal manager starts it immediately.

Reviewing a Specific Manager

View details of a concurrent manager's operation.

Processes	You can view the details of the processes of a given concurrent manager. Processes that are currently active, migrating, or terminating, as well as processes that have been terminated or deactivated, are displayed.
Requests	For a selected manager you can view all running and pending requests handled by the manager.

Managing Parallel Concurrent Processing

This essay describes how to manage parallel concurrent processing from System Administration forms. It presents the following topics, each in the context of parallel concurrent processing:

Defining Concurrent Managers

You define concurrent managers using the Concurrent Managers window. When you define a manager, you specify the manager type, which may be either "Concurrent Manager", or "Internal Monitor". There is a third manager type, "Internal Concurrent Manager", that describes the Internal Concurrent Manager process that Oracle Applications predefines for you.

Attention: When using parallel concurrent processing, manager names cannot have embedded spaces in them. Name your managers using one word, or connect two words using a hyphen (manager-name) or underline (manager_name).

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.

Administering Concurrent Managers

Target Nodes

Using 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.

When a manager's 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.

Control Across Nodes

Using the Administer Concurrent Managers form, you can start up, shut down, migrate, 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 Manger from any node in your parallel concurrent processing environment.

Starting Up Managers

You start up parallel concurrent processing by issuing an "Activate" command against the Internal Concurrent Manager from the Administer Concurrent Managers form, or by invoking the STARTMGR command from the operating system prompt. Regardless of the node from which you activate the Internal Concurrent Manager, it starts up on its assigned node (assuming that you operate from a node whose platform supports remote process startup.)

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.

Shutting Down Managers

You shut down parallel concurrent processing by issuing a "Deactivate" command against the Internal Concurrent Manager from the Administer Concurrent Managers form. All concurrent managers and Internal Monitor processes are shut down before the Internal Concurrent Manager shuts down.

Migrating Managers

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 effect your changes, you issue a "Verify" command against the Internal Concurrent Manager from the Administer Concurrent Managers form.

Terminating a Concurrent Process

You can terminate a running concurrent process on the local node or on remote nodes by issuing a "Terminate" command from the Administer Concurrent Managers form.

Administering Concurrent Managers

Target Nodes

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.

Control Across Nodes

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

Starting Up Managers

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.

Shutting Down Managers

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.

Terminating Concurrent Processes

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.

Migrating Managers

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

Administer Concurrent Managers Window

View the status of your concurrent managers (including any transaction managers) and, if you wish, change the status of any manager by issuing a control command. For example, you can deactivate a manager that is currently active, then view its new status after the change takes effect.
Use the Refresh button to refresh the data shown.

Reviewing a Specific Manager

View details of a concurrent manager's operation

Variable	Description
Processes	You can view the details of the processes of a given concurrent manager. Processes that are currently active, migrating, or terminating, as well as processes that have been terminated or deactivated, are displayed.
Requests	For a selected manager you can view all running and pending requests handled by the manager.

The following actions are available only for certain services managed Generic Service Management. These services must be defined to accept commands to suspend their operations.

Variable	Description
Suspend	Suspend the operations of the service.
Resume	Resume the operations of the service.

Related Topics