The times between creation of a print job and the actual printout become increasingly longer.
The runtime of the spool work process increases continuously in the process overview and is finally marked as red. The CPU time hardly increases at all. The status is shown at the same time as a sequential read operation on table TSP02 by the program RSPOWP00.
The fact that the ABAP/4 program RSPOWP00 is occupying the spool work process is correct; this is the ABAP/4 screen for the C program of the spool work process that is processed by the work process. However, the user may be set incorrectly; this will not have any effect on the functions.
The cause of the long delays when printing is that print jobs are being created faster than can be sequentially processed by the spool work process.
This causes longer and longer wait times. The spool work process carries out a search for lost jobs in table TSP02 every 20 minutes (this may occur due to an overflow in message queues), to ensure that all orders are actually processed. If more jobs are created in 20 minutes than can be processed, the work process leaves its standard routine and processes the currently remaining jobs until they are all processed. As the jobs are being created too quickly, it never completes this task. This is reason for the increasing time specification in the process overview. It is only reset if a new request is taken from the dispatcher, but the the search for jobs is only a single request, whose processing is not exited in the situation stated. All further jobs are processed in this search mode.
The search used by the work process is not handled via an index, so that a Full Table Scan is executed for each job (see Note 64979). This requires several seconds and is therefore considerably longer than the normal print mechanism. This results in the database load becoming greater and the problem being aggravated.
In addition, no further messages are accepted from the dispatcher, so configuration changes (for example changes to printer definitions or device type definitions) no longer take effect for this spool work process.
This vicious circle can only be exited if no new jobs are created for this spool work process until all previous ones are processed!!!
This can be achieved by distributing the printers in question to other servers. The printers can also be blocked within R/3. Both of these options can be changed in Transaction SPAD when defining output devices.
In order to avoid this in the future, you must prevent jobs from being created faster than they can be printed. The only way to achieve a solution to this problem is to adjust the system configuration to the high print load. The following options are available to increase the throughput:
1. Redistribute the printers assigned to the spool work processes or configure further spool work processes and split the printers up.
Production printers should be assigned as well separated as possible so that their printing is not affected by other jobs.
As only one spool work process is possible for each instance, further instances that are not used for dialog can also be set up for this purpose (note that you need two dialog work processes here). You can also run several instances on one host, but this is only useful if several processors are available or the availabel processor(s) are not busy.
2. As an additional measure, for all printers on a particular spool work process (for example, for the critical production printers assigned to a WP), you can deactivate the host spool confirmation request (SPAD printer definition), to further reduce the load on the spool work process).
3. Configure the message control or other print data generation system so fewer, larger print jobs are created.
The processing of a print job, regardless of the number of sides, requires a considerable overhead when preparing the print process. It is therefore more favorable to use fewer print jobs but with a larger number of printed pages.
4. Create spool requests preferably with the option "Delete after successful print".
As a result, the number of table entries in table TSP02 is kept as small as possible. At the same time, you should ensure that there are sufficient free spool numbers (currently limited to 32000).
5. If possible, do not use network access methods (S or U), but local ones, such as L or C.
If you use network access methods, any network problems (such as timeouts or long connection or transmission times) will immediately affect the spool work process. As one spool work process is generally not responsible for just one printer, jobs for other printers may also be affected.
6. Always configure network printers via a host spool system.
Most network printers cannot correctly simulate a host spool system, as they do not have hard disks to spool incoming jobs. However, this is required by R/3. If this requirement is not met, jobs cannot be printed correctly if there are several jobs within a short time. In this case, they are set to the status "incorrect" or the printer is blocked by R/3 so that a printout is only carried out approx. every 5 minutes.
As of Release 4.0A, you can configure several spool work processes per instance.
This should prevent this overload problem. Please also refer to Notes 108799 und 118057.
As of Release 3.1G a patch is available which simplifies conditions of selection so that is is possible to use an index. This should cause a considerable acceleration. Nevertheless, the problem which makes costly exception treatment usual is thereby not solved (Note 64979).
As of Release 3.1H another patch is available which reduces the number of scans required (Note 72767). However after implementing Note 72767 you should take the measures described in this note to avoid overload situations!