Oracle EBS Concurrent Manager — Inactive / No Manager: Root Cause, Diagnosis & Fix

📊 Oracle EBS DBA Series

Oracle EBS Concurrent Manager
Inactive / No Manager

Root cause, diagnosis & fix — with SQL scripts, OS commands, and proactive monitoring tips

👤 Oracle EBS DBA Specialist Lead 📅 June 2026 🕐 7 min read 🏭 Database: WCGATDB

You submit a concurrent request in Oracle EBS — maybe an AP Invoice Import, a Payee Import, or a custom XX program — and instead of "Pending → Normal", you see the two most dreaded words on the Requests screen:

Request 919988 — XX Payee Import (Providers) Inactive No Manager

This article breaks down exactly what this means, why it happens, and the step-by-step DBA fix to resolve it fast — whether you are on-premise or on AWS.

What does "Inactive / No Manager" mean?

Oracle EBS uses the Concurrent Processing (CP) framework to run background jobs. Every request is handled by a Concurrent Manager — specifically by a Work Shift assigned to that manager that is active at the time.

When you see Inactive / No Manager, Oracle is telling you:

No Concurrent Manager is currently running that is eligible to process this request
The request matched no active Work Shift, or no manager is up
The Internal Concurrent Manager (ICM) may itself be down

💡 Tip

Think of the ICM as the "supervisor" and the specific managers (Standard, Payables, etc.) as "workers". If the supervisor is down, no worker gets assigned.

Common root causes

#	Root Cause	How to Confirm
1	Internal Concurrent Manager (ICM) is down	Check FNDSM / CM status in sysadmin
2	Standard Manager work shift not covering current time	Query FND_CONCURRENT_QUEUES
3	No work shift defined for custom manager	Check manager config in System Admin
4	Specific program assigned to manager with no active workers	Check manager specialization
5	Database listener or APPS connection issue	Check alert.log, tnsping
6	Adcmctl / OPMN services not started after patching	Run adcmctl.sh status
7	OS-level adop / patching left CM in stopped state	Review recent patch history

Step-by-step diagnosis

Step 1 — Check CM status from the front end

Navigate to: System Administrator › Concurrent › Manager › Administer
Check that Internal Manager shows Active status
Check Standard Manager — Actual Processes should be > 0
Look for any manager showing 0 Actual / 0 Running

Step 2 — Check at the OS level (EBS App tier)

# Source the environment
. /home/applmgr/<CONTEXT_NAME>.env

# Check CM processes
ps -ef | grep FNDLIBR
ps -ef | grep ICM

# Check adcmctl status
adcmctl.sh status apps/<apps_pwd>

Step 3 — Query the database directly

-- Check manager status
SELECT CONCURRENT_QUEUE_NAME,
       MANAGER_TYPE,
       RUNNING_PROCESSES,
       MAX_PROCESSES,
       WORKER_COUNT
FROM   FND_CONCURRENT_QUEUES_VL
WHERE  ENABLED_FLAG = 'Y';

-- Check if ICM is alive
SELECT NODE_NAME, STATUS_CODE
FROM   FND_CP_SERVICES
WHERE  SERVICE_HANDLE = 'FNDCPGSC';

Step 4 — Check work shifts

SELECT Q.CONCURRENT_QUEUE_NAME,
       W.SHIFT_NAME,
       W.FROM_TIME,
       W.TO_TIME,
       W.WORKERS
FROM   FND_CONCURRENT_QUEUES Q,
       FND_CV_SHIFTS_V W
WHERE  Q.CONCURRENT_QUEUE_ID = W.CONCURRENT_QUEUE_ID;

The fix — how to resolve it

Fix A — Restart the Concurrent Manager (most common fix)

# Stop all concurrent managers
adcmctl.sh stop apps/<apps_password>

# Wait 30-60 seconds, verify all FNDLIBR processes are gone
ps -ef | grep FNDLIBR | grep -v grep

# Start concurrent managers
adcmctl.sh start apps/<apps_password>

# Verify startup
adcmctl.sh status apps/<apps_password>

⚠️ Warning

Never hard-kill (kill -9) the ICM without a full stop/start cycle. This corrupts the CM state in FND tables and requires manual cleanup.

Fix B — Verify work shifts are configured

Go to: System Administrator › Concurrent › Manager › Define
Select the relevant manager (e.g., Standard Manager or your custom XX manager)
Click Work Shifts button
Ensure a shift exists that covers the current time (or use "Any" shift = 24x7)
Set Workers to at least 1 (or match your workload)

Fix C — Deactivate & reactivate from Administer screen

Navigate to: System Administrator › Concurrent › Manager › Administer
Select the problematic manager
Click Deactivate, wait 10 seconds
Click Activate — this forces the ICM to reassign workers

Fix D — Resubmit the request

Once managers are confirmed Active with processes > 0, resubmit the original request. Oracle EBS does not automatically retry Inactive/No Manager requests — you must resubmit manually.

Real-world case: XX Payee Import (Providers)

Request ID 919988 — XX Payee Import (Providers) — was sitting with Phase: Inactive, Status: No Manager in database WCGATDB. Investigation revealed:

The Standard Manager was up but had 0 Actual Processes due to a stale CM lock
An adcmctl.sh stop/start resolved the stale lock
After restart, resubmitting moved the request to: Pending → Normal → Complete ✓

💡 Tip

Always check if this affects only ONE specific program or ALL requests. If all requests are stuck, it is an ICM issue. If only one program, check program specialization rules on that manager.

Prevention: proactive monitoring

Check	Method	Frequency
ICM running	ps -ef + FND_CP_SERVICES query	Every 5 min
Manager actual processes = 0	FND_CONCURRENT_QUEUES_VL query	Every 10 min
Requests stuck > 30 min	FND_CONCURRENT_REQUESTS query	Every 15 min
Alert log CM errors	grep FNDLIBR alert.log	Hourly
adcmctl.sh status check	Shell script + email alert	Daily

-- Requests pending > 30 minutes with no manager
SELECT REQUEST_ID,
       CONCURRENT_PROGRAM_NAME,
       PHASE_CODE,
       STATUS_CODE,
       ROUND((SYSDATE - REQUEST_DATE)*1440,1) AS WAIT_MINS
FROM   FND_CONCURRENT_REQUESTS
WHERE  STATUS_CODE = 'I'
AND    PHASE_CODE  = 'I'
AND    (SYSDATE - REQUEST_DATE)*1440 > 30
ORDER  BY REQUEST_DATE;

Quick reference card

Symptom	Most likely cause	First action
All requests → No Manager	ICM down	adcmctl.sh stop/start
One program → No Manager	Manager specialization / no shift	Check Define Manager › Work Shifts
After patching → No Manager	CM not restarted post-patch	adcmctl.sh start
Intermittent No Manager	Work shift gap (midnight window)	Add 24x7 "Any" shift
No Manager after failover	CM pointed to wrong node	Check APPL_TOP / opmn.xml

Conclusion

The Inactive / No Manager error in Oracle EBS is almost always solvable quickly once you understand the Concurrent Manager architecture. The key steps are:

Verify ICM and manager status from the Administer screen and OS
Run adcmctl.sh stop/start if CM processes are absent
Check work shifts if only specific programs are affected
Resubmit the request — it will not auto-retry
Add proactive monitoring to catch this before users report it

These day-to-day fixes are what separate a reactive DBA from a proactive one. If you found this useful, share it with your EBS DBA team.

#OracleEBS #ConcurrentManager #EBSDBA #OracleApps #NoManager #OracleDBA #EBSAdmin #Exadata #AWS

Database Consultant (Passionate about Database & Cloud Technologies)

Thursday, June 25, 2026