Spool Service (AS ABAP) 
This section describes the possible reasons for failure in the spool service and describes how you can increase its availability.
Features
Each of the following components is involved in the SAP spool service and each can fail:
Spool work process (this prepares the output data and processes the print job)
Database service and file system of operating system
Number range service
Destination host
Host spool system
Output device (for example, printer)
For access methods S and U, SAPSprint Service
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.
The spool service needs the database service to function. Control information for the spool requests and, if so configured, the output print data itself, are generally 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.
Note
Spool requests that were created with Adobe Document Services (ADS) are stored in the file system, not in the TemSe.
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. A single spool server can support multiple spool work processes.
Note
For Adobe printing, the work process simply forwards the data without processing it.
Configuring Printer Services with Virtual Addressing
To increase resilience of the spool and print service, you can use virtual addressing for the application server name of the AS spool instance, which is normally the primary application server (PAS) instance. It is essential to keep the printer device accessible for the spool work process. Therefore, do not attach printers directly to a specific AS host machine. Instead attach them to a print server that remains transparently accessible with a constant network name after switchover on the AS cluster.
Use transaction SPAD to define a printer.
Logical Spool Server Definitions
It is possible to configure logical spool servers within transaction SPAD. For a failover configuration, these logical spool server definitions can be used to switch a spooler service from a failed application server to an application server that is still running. This switchover occurs automatically, minimizing interruption to print processing.
For more information about logical spool server concepts, see the SAP Printing Guide and SAP Note 118057.
Activities
Recommendation
Monitor the spool system to identify problems before they affect the availability of your spool service.
When a spool server fails
An output device is tied to a single spool server. Do the following:
Reassign printers from a failed spool server to a new spool server. Refer to Assigning Output Devices to Another Server.
To anticipate the problem, set up multiple and alternate spool servers to increase the availability of your spool service. You can also implement load balancing for the spool service.
When the database service fails
If the database service fails, no further spool requests can be generated and the following applies:
Existing spool requests that have not yet been processed are not lost but they cannot be processed.
Spool requests for which output requests have already been passed to the host spooler or SAPSprint Service before the database service failure are processed by the host spool system. However, it is not possible to write a corresponding entry indicating success in the log table for the spool request.
For more information about SAPSprint, see SAPSprint Service.
The spool service is unavailable for the period when the database is down.
You must now check the consistency of the spool database.
When SAPSprint, the destination host, or the host spool system fail
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 SAPSprint, destination host, host spool system).
For more information, see Problem Analysis: Print-Out Missing or Incorrect.
When the spool work process fails
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.
When the output device (for example, printer) fails
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 it might arise 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:
Do not set the flag “delete after print”.
Set the “retention period” to a high value (for example, 8 days), so that these spool requests are not deleted.
For more information, see Displaying and Changing Spool Request Information.
When a failed output device cannot be repaired
If an equivalent device is unavailable, 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 Displaying and Changing Spool Request Information. You can redirect spool requests from list-type output (that is, from SAP reports), assuming the spool type and print control exist on the different device type, but not output from SAPscript.
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.
For more information, see Assigning an Output Device to a Pool.