Lesson 2 of 5
Work processes and sessions
10 min
Listen to this lesson
When users say "the system hangs", the first place to look is what the system is actually doing. Every request in an ABAP system is processed by a work process, so the work process overview shows what is running, for whom and for how long. This lesson shows how to read it to find long-running and blocking work.
| Transaction | Shows | Use it to |
|---|---|---|
SM50 | Work processes of the current instance: type, status, reason, time, program, client, user | Find what is running now on one instance and for how long |
SM66 | Active work processes across all instances | See the whole system at a glance; spot one program hogging many processes |
SM04 | User sessions on the instance | See who is logged on, from where, and how many sessions they hold |
SM51 | Application server instances of the system | Jump to an instance; check which servers are active |
SM37 | Background jobs | Link a busy background work process to its job and owner |
Reading the work process overview
Each line in SM50 is one work process. The columns that matter most are type (dialog, background, update, spool), status (such as waiting, running, on hold or stopped), the reason a process is on hold, the time it has spent on the current request, and the program, client and user it is running for. A healthy instance has some dialog work processes waiting at all times. If every dialog process is running or on hold, new requests queue in the dispatcher and users experience a "hang".
Patterns to recognize
- One program, many processes, long times: a heavy report started by many users, or a mass job run in dialog. Move it to background or tune it.
- Many processes on hold waiting for RFC: a remote system is slow or down. Check the destination and the partner system before touching the local system.
- Processes waiting on locks or database: look for the holder: a long update, a background job, or a stuck session.
- One user, many sessions: an automated test or interface opening sessions without closing them. Check SM04 and the test design.
- Background processes all busy and jobs stuck in Ready: too many parallel jobs for the configured background capacity.
Acting on a work process
From SM50 you can cancel a work process's current request, preferably without writing a core file unless SAP Support asks for one. Cancelling ends that user's or job's request, which may leave a half-finished business transaction to be cleaned up, so do it only after identifying the owner and the consequence. If the dialog system is so blocked that you cannot even log on, SAP training points to the operating-system tool dpmon, a text-mode dispatcher monitor that can show and stop work processes for an instance.
- DetectAt 09:05 Maria's team reports frozen screens in CMQ
- SM66All 20 dialog work processes busy; 14 run the same custom stock report, each for over 10 minutes
- SM04 and SM50The report was started by an automated test suite with 14 parallel users
- ActAgree with Priya to stop the suite; cancel the 14 requests; screens recover
- PreventSuite moved to its own logon group and the report scheduled in background for the test
What would you do?
CMQ is slow. SM66 shows most dialog work processes on hold waiting for an RFC to the legacy warehouse system. What is the most useful next step?
- SM50 shows one instance's work processes; SM66 shows active processes system-wide; SM04 shows user sessions.
- Read type, status, reason, time, program and user together.
- No free dialog work process means queued requests: the classic "hang".
- Identify the owner and consequence before cancelling; dpmon helps when you cannot log on.
Check your understanding · not graded
Lesson check
1. Which transaction shows active work processes across all instances?
2. What does it mean when every dialog work process is running or on hold?
3. Many processes are on hold waiting for RFC. Where is the bottleneck most likely?
4. Which tool helps when the dialog system is too blocked to log on?