SAP Spool Service
This section describes the possible reasons for failure in the SAP spool service and describes how you can increase its availability.
Each of the following components is involved in the SAP spool service and each can fail:
The spool service does not work with transactions, as happens in the database service. Therefore, if a printout is incomplete due to a failure in the output device, the printout is not rolled back in the same way that database transactions can be rolled back. Instead, such a spool request is in most cases marked as "completed" in SAP.
Thespool service needs the database service to function. Control information for the spool requests and, if so configured, the output print data itself, are stored in database tables. Output print data is stored in the Temporary Sequential Objects (TemSe) database. To improve system performance and reduce the size of the database, you can move the TemSe database to the file system. For more information, see Administering the TemSe Database.
The spool work process is responsible for preparing the output data, processing the output request, and passing the output request data to the host spool system. Spool work processes run on the spool server. This host is known as the "spool server". A single spool server can support multiple spool work processes. Refer toMultiple Spool Workprocesses.
Monitor the spool system to identify problems before they affect the availability of your spool service.
An output device is tied to a single spool server. Do the following:
If the database service fails, no further spool requests can be generated and the following applies:
For more information about SAPLD, see
You must now
In this case the spool request cannot be successfully processed. Such requests are sometimes set to "failed" in the corresponding spool table entries and you can manually restart them, once you have fixed the original problem (that is, the failure in the program SAPLPD, destination host, host spool system).
In this case the dispatcher restarts the failed spool work process. Then the relevant "administration transaction" on the database is rolled back, so that the uncompleted spool requests are not deleted. The new spool work process then takes over the work of the terminated one.
In this case the spool request is usually not set to "failed" in the log table. Instead it is normally set to "completed". For example, this situation might arise because the host spool system incorrectly reports successful processing or because the host spool system does not report anything and processing is assumed to be complete, once the output request has been passed to the host spool system.
So that you can manually restart such spool requests, do the following:
You can avoid the manual restart if the host spool system itself automatically repeats the output request, once the existing device has been repaired or an equivalent device has been installed and defined to the host spool system. In this case, the spool request in the log table is not defined as failed since the host spool system has not reported a failure.
If an equivalent device is not available, then it is not possible to satisfactorily print the output requests that were prepared for the failed device type on a different device type. You need to regenerate the spool requests in this situation, or alter them, so that they can be printed on a different device type. For more information about printing on a different device type, see
You can define a "device pool" containing equivalent devices. If a device defined in a device pool fails, you must remove the failed device from the device pool using the spool administration (transaction SPAD) so that the failed device does not receive any further requests. The device pool continues operating after the failure of a device but with reduced throughput. Any requests that were assigned to the failed device before it was removed from the pool are not automatically redirected to functioning devices in the pool.
Refer toAssigning an Output Device to a Pool.