SM66 — Global Work Process Overview

SM66 shows the current state of every work process across all application servers of a system in one screen: process type, status, user, program, table accessed, CPU time, and elapsed time. The structural fact that causes most confusion is that this list has no persistent backing table. Each time the screen refreshes, the kernel dispatcher on the presentation server issues RFC calls to the dispatcher of every other application server, asks for its local work process table, and assembles the result on the fly. What is displayed is an instant, unlogged snapshot. Nothing is written anywhere, there is no history, and a process that looks stuck at the moment of the call may already have finished or changed state by the time a decision is made about it.

SM66 is reached for the moment a performance problem is suspected to be system-wide rather than confined to the instance currently logged into: dialog queues piling up, background jobs not progressing, or a batch load pinned during a cutover window. It is the natural escalation from SM50, which only shows the local server's work processes and will show nothing if the actual blocking process sits on a different application server. It is not used for authorization, user session management, or long-term trending; ST03 and ST06 cover workload history and OS-level resource use respectively, and SM04 covers user-to-session mapping rather than process-to-server mapping.

SM66 itself cannot be reproved in SE16 because nothing it displays is stored. To confirm a symptom after the fact, work backward from the timestamp noted during the incident: check the system log for RFC or communication errors from the affected server around that time, or pull workload statistics for the same time window to see whether response times or wait times spiked on that instance. If a process was cancelled with core, the resulting short dump carries the exact timestamp, user, and program, which is the closest thing to a persisted record of what SM66 showed.

SM66 is unchanged on S/4HANA. It remains a classic dynpro transaction with no dedicated Fiori replacement, and Basis teams continue to use it exactly as on ECC for cross-server work process troubleshooting. HANA-specific database load is better diagnosed through the HANA-aware monitoring transactions rather than through SM66, which stays focused on the ABAP application server layer regardless of the underlying database.

This is purely Basis territory. Functional consultants may be asked to identify which transaction or job is stuck, but the decision to cancel a work process belongs to Basis, since an ill-timed cancel on an update or enqueue process can leave inconsistent data. A good handover names the server, process number, program, and elapsed time observed, plus the exact timestamp of the SM66 snapshot.

SM50 is the natural companion, showing the same data scoped to a single server, and is the first stop when the affected instance is already known. SM51 lists the servers themselves and is useful to confirm which instances should even appear in the SM66 aggregate. SM04 maps users to sessions rather than processes to servers, useful when the question is who is logged in rather than what is running. SM21 gives the system log needed to cross-check an RFC failure noticed during an SM66 poll, and ST06 gives the OS-level resource view that explains why a process was consuming so much CPU or memory in the first place.