SAP Note 16772 - Dispatcher queue for the spooler

Symptom:

Many (or too many) entries sometimes appear in the Dispatcher queue for the spool ("SPO"). What are they doing there?

Cause and prerequisites

Not an error -- request for information

Solution

Contents
What does the dispatcher queue do?
Which items run through the spooler dispatcher queue
Many wait loops
Massive reconfigurations
RESET N1

1. What does the dispatcher queue do?

The dispatcher manages several queues for messages that are sent between the various work processes. By using the message server, such messages can also be exchanged among several dispatchers throughout a complete R/3 System, thus reaching the work processes of other application servers.
One of these queues is dedicated for messages to the spool work processes.
Unfortunately, there is no way to examine the contents of the queue. You can check the fill level, however, using the SAP program 'dpmon':

1.1 Starting 'dpmon' from within R/3

->Tools ->Administration
->Computing Center ->Management System
->Control ->Startup/Shutdown ->Start Control Panel (RZ03)
Place cursor on the instance with the spool work process
->Choose
->Tools ->Dispatcher Monitor

1.2 Starting 'dpmon' from UNIX

The SAP program 'dpmon' is contained in the same directory as 'disp + work' or 'dwora' or 'dbinf',... and is started with the same profile.
Example for UNIX:
cd /usr/sap/C11/DVEBMGS00/work
ls -l dw.sap* ;: indicates the EXE directory
head stderr1 ;: indicates the profile
/usr/sap/C11/SYS/exe/run/dpmon \
pf=/usr/sap/C11/SYS/profile/C11_DVEBMGS00

1.3 dpmon

The output has an "SPO" line and should be refreshed every few seconds. Typical values for a normal system are:
now | high | max | writes | reads
-----------------------------------------------
1 | 12 | 800 | 4325 | 4311

"max" is set by the profile parameters. "high" is the highest value that has occurred since the application server was started. When "now" = "high", then you're just in time to see the worst case.
When "now" (and "high") approach "max", the wait queue is full. This should never happen. When it does, however, R/3 instances with older releases (2.1F, for example) lock up! In later releases, surplus messages are destroyed.
"writes" and "reads" count how many messages were placed in the queue and removed (e.g. delivered) since the application server was started up.

2. Which items run through the spool dispatcher queue?

2.a Announcements for output requests
When someone generates an output request, it is written to table TSP02, and a message with the database key is sent to the appropriate spool work process.

2.b Resets
When configuration tables relevant for the spooler are changed, all affected spool work processes are informed. This generally occurs with and within transaction SPAD (spool administration).

2.c "Check yourself" mesages
Whenever someone calls transaction SP01 (output control), the spool work processes are informed.
The spool work processes then check whether any half-finished actions exist, and refresh the status messages in the database when necessary.

2.d Host spooler query requests
A spool work process sends such messages to itself with a time delay. This ensures that the host spooler is queried regularly, but not to often, whether the requests that were passed on have been completed. (Release 2.x only)

2.e Wait messages
In Release 2.x, the dispatcher cannot generate messages; it can only forward them. Therefore, when the spool work process wants to wait, it must wait actively. This means that it deactivates itself for a while (library function sleep()). During this time, it is occupied as far as the dispatcher is concerned, and does not receive any additional messages.
As a result, pauses that are too long may occur, e.g. a minute is divided into sections of 5 seconds each. The spool work process then sleeps for 5 seconds and sends a message "55 seconds more" to itself. This message is added to the end of the dispatcher queue. The spool work process then generates all the other messages that it received from the dispatcher in the interim. When the wait message is returned, the spool decides whether to reject the message or to sleep another 5 seconds.
(Release 2.x only)

2.f Wake messages
In newer systems, the dispatcher regularly (e.g. once a minute) generates a wake message for the spool work process. This regularly activates the spool work process. Each time, it checks its internal administration data to see whether actions were delayed that it must now perform. With this method, almost all sleep () commands, the wait messages (2.e) and the host spooler query requests (2.d) could be removed.
(Release 3.0 and later)

3. Many wait queues

When the queue retains a consistently high level, but over 20 messages are processed in a minute, then the problem from note no. 12195 is probably to blame: "Check yourself" messages that process the output requests before the print request messages have been forwarded from the queue.