📊 Oracle EBS DBA Series
Oracle EBS Concurrent Manager
Inactive / No Manager
Root cause, diagnosis & fix — with SQL scripts, OS commands, and proactive monitoring tips
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:
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
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>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/startresolved the stale lock - After restart, resubmitting moved the request to: Pending → Normal → Complete ✓
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/startif 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.
