A failed printout can delay or disrupt important meetings or cause you to miss deadlines. See how to avoid printer failures when using SAPSprint by analyzing the three most common types of errors. Also find answers to common SAPSprint issues in the SAPSprint FAQs.
Key Concept
Processing in SAPSprint involves generating print data via the Windows Graphics Device Interface and routing the print data to the selected printer.
It’s the end of the quarter and the financials team needs to print out a series of reports. It sends the reports to print, but an error occurs with SAPSprint and stops the printing process. The team is on a tight deadline and needs the reports as quickly as possible. It’s up to you to ensure the team has the reports in time.
Three main categories of problems — communication errors, job processing errors, or problems with the physical printer — could be the root of the blocked printing. I’ll explain how you can use trace files to view the logged errors and then describe how you can solve each category of error. In cases of very specific problems, you may need to involve SAP support. By going through the processes in this article, you’ll uncover valuable information for your discussion with SAP support. At the end of the article I provide SAPSprint FAQ to answer common questions about problems with SAPSprint.
Trace Files
Before discussing the main error categories, let’s take a look at the trace files. All detected errors during processing are logged in the trace files. If no error could be detected, the trace files show the work flow stages during processing. SAP trace files help SAP find the necessary information SAP support needs to find the root cause for the problem in the coding.
A general trace file sapsprint.dbg is generated with at least LogLevel 1 in the LogPath. A job-specific log file sapwin_<Jobname>.log is also generated in the LogPath. LogLevel and LogPath are SAPSprint options. See my first two articles for information about how to set up these files. <Jobname> is part of the log file’s name according to the following naming convention:
- <SID><Spool-ID>_<Output-ID> — e.g., ABC0000012345_1 for the S protocol
- dfA<3 Digits><Name of the SAP server> — e.g., dfA001lambik01 for the U protocol
Leave all trace options set to the default values if you are in a normal productive environment. You should change the values only for problem analysis. Make sure you reset the values to the defaults after you fix the problem to avoid performance issues and excessive disk space consumption.
I’ll discuss the most common trace options. Trace options should be on the lowest level for normal processing because the system generates a significant amount of trace information, which uses unnecessary disk space and slows down performance.
The general trace file sapsprint.dbg is written with basic logging for each job with LogLevel 1. With each restart of the SAPSprint service, the old trace file is archived with a time stamp extension in the LogPath. The same is true if the maximum size is reached. You can set the maximum size with the MaxLogFileSize option. If you don’t need these archived log files, you should delete them from time to time to save disk space.
The job-specific log file is only kept in the LogPath if an error is detected during job processing. Otherwise, the system deletes it with the print data file after job processing has finished. Save the file by using the KeepFile option so you can send the print file to SAP support to enable them to reproduce the problem with the printout.
The first task during error analysis is to watch LogPath. Ideally, only the current sapsprint.dbg, the archived ones, and various print data and job-specific log files, which are deleted again after printing, should be available in the LogPath. If you see more files, it could be because someone accidentally set the KeepFile option or insufficient housekeeping after error analysis.
Error Categories for Problems
As mentioned earlier, most errors fall into three root categories:
- Communication errors
- Job processing errors
- Problems on the physical printer
If the system detects something wrong, it lists the problem details in transaction SP01 (Output Controller). Print jobs can have Completed, Problem and Error statuses. If the spool request is not yet printed the status field contains a minus (-) sign. Figure 1 shows a spool request with the statuses Error, Completed, and Problem. Error and Completed are final status, and Problem is a non-final status.
Figure 1
Job status in transaction SP01
Printers become locked from the SAP system after an error occurs. For example, if a print job could not be transferred to SAPSprint because of a network problem, the printer is locked to prevent the system from running into the problem again. New jobs for locked printers automatically get the status Problem, which causes the list with bad print requests to grow. You can re-enable the printer in transaction SPAD after you find the root cause of the problem.
Communication Errors
Often when network problems occur with SAPSprint, the typical answer is “the network is working fine except for printing.” However, if a connection interruption happens frequently, and the problem is not an error in job processing, there is a network problem.
Communication errors fall into two categories:
- The connections cannot be established at all
- An established connection is interrupted
In both cases, the system displays an error message in the trace file of the spool work process. The second communication error also displays an error message in the sapsprint.dbg log file.
If the printer is configured correctly in the SAP system and you cannot establish the connection, you should check the following in order:
- Is the print server available?
- Is the SAPSprint service running?
- Is the TCP/IP port configured in the SAP system the same as specified in the LPDPort option?
- Is any firewall software blocking requests between the SAP application server and the print server?
If you answer any of the first three questions “no,” check the configuration according to the description in the first article. If the answer to the last question is no, talk to your network administrator to make sure that the configured TCP/IP port (usually 515) is not blocked by firewall software.
The easiest way to check a connection’s status is to use the connection test in transaction SPAD. Go to Output Device > Check connection (Figure 2). Figures 3 and 4 show the result of the check for a running and non-running SAPSprint, respectively.
Figure 2
Printer connection check
Figure 3
Connection check: the SAPSprint connection is running
Figure 4
Connection check: the SAPSprint connection is interrupted
Note
Connections can be interrupted for many different reasons. Therefore, I can only provide a few general recommendations and hints. You should consult SAP support for help with specific problems.
To explain how a connection can be interrupted, let’s take a closer look at the protocol. A connection is not interrupted like cutting a pipeline. Both protocols used in the communication with SAPSprint are handshake protocols. Data is sent from the SAP system to SAPSprint. Depending on the kind of data, SAPSprint expects an answer from the SAP system within a certain amount of time. Sending and receiving occurs frequently on both sides until all data is transferred. If SAPSprint does not receive an answer to one of the send requests within the expected time, the network layer reports an error. This error is reported to the caller — either the SAPSprint service or the SAP spool work process — and the connection is interrupted.
If the system does not send an answer to a request, the cause is usually one of two reasons: Either the process cannot send because it is blocked or the network is too slow. If the SAPSprint process is blocked, the most probable reason is a problem during job processing. To determine if this is the case, you should compare the time stamps of the connection problem in the SAP spool work process trace with the time stamps of job- specific log files or the time stamp of the SAPSprint service restart in the Windows event log. If they correspond, the root cause of the problem is not the network, but a problem in job processing. If not, the network is the problem.
Job Processing Errors
If a problem is detected during job processing, a job-specific log file is always generated in the LogPath. The print data file is kept together with the log file. The general log file sapsprint.dbg contains an entry that the job is finished with a return code greater than 0. Usually this only happens when processing SAPWIN jobs.
The job-specific log file contains the name of a Windows Graphics Device Interface (GDI) call that caused the problem and the corresponding error message returned from Windows. CreateDC is usually the call that caused the problem when the error message is “finished successfully.”
This contradiction occurs because the error message is returned from another Windows call, which receives the last detected problem within the Windows GDI. Each GDI call triggers an error message if a problem is detected. The Windows GDI uses other programming interfaces from the printer drivers that are provided by printer vendors. If an error occurs in a printer driver, the driver should set an error message in the GDI layer. However, this error occurred in a deeper layer (the printer driver) of the system. Often printer driver software does not set a correct error message. Because of the missing error message, the GetLastError call assumes that everything is fine, even though you are experiencing a problem.
SAP discovered that many printer drivers cause problems in a long-running service such as SAPSprint, which handles thousands of jobs. During processing, the same Windows GDI calls are called again and again. Suddenly, some of them fail. CreateDC has the highest probability of failure because during this call some resources are allocated, and the missing resources cause the fail. The failing call is logged in the job-specific trace file. When the problem occurs, no further processing is possible.
SAPSprint has a built-in mechanism to restart itself after it detects the CreateDC error. With the restart mechanism, the problem on the printer server is minimized. No print job becomes lost and the service works fine again after the restart. (If a different call causes the error, you must restart SAPSprint manually.)
Note
The printer driver problem does not occur with SAPWIN and front-end printing or with SAPSprint using raw printing with native SAP device types such as POST2 for PostScript printers. This is because raw printing does not use the GDI calls at all and front-end printing only prints a few jobs during process runtime compared to the long-running SAPSprint service.
The SAP system locks the printer if it cannot connect to SAPSprint to prevent an unnecessary load on the network. However, the restart from the CreateDC error only lasts one or two seconds, so the system doesn’t need to lock the printer. You can set the profile parameter with the profile maintenance transaction RZ11 (Figure 5). Change the profile parameters to the following:
- rspo/tcp/retrytime = 1
- rspo/host_spool/check_retries = 5
- rspo/lpq/temp_disable_time = 1
Figure 5
Enter the parameter name and click the Change button
Shortening retrytime and temp_disable_time profile parameters to 1 prevents the printers from being locked. Check_retries is the number of retries the SAP system attempts to establish a connection to SAPSprint before the job gets an error state.
Note
You can change the profile parameters only if you are using SAPSprint on the print server. If you use another service that does not automatically restart, you must use the default values.
The restart mechanism might be ineffective if the CreateDC error occurs too often, which leads to a restart loop of SAPSprint in a worst-case scenario. If the CreateDC error occurs too often, which is rare, the problem is in the server. In this case, restart the print server on which SAPSprint is running.
Another problem might be that the restart lasts too long because of huge job lists processed during restart. You should investigate such problems with SAP development support.
Problems on the Physical Printer
Typical problems with the physical printer include:
- Printer is paused
- Printer has no paper
- Printer tray is not closed
- Printer has no toner
- Printer is switched off
- Printer share is not available
Theoretically, an error code for each of the above problems is defined in the Windows GDI interface that SAPSprint is using to detect the job status. However, the system often only indicates when the “printer is paused” problem occurs. The other problems (e.g., the toner problem) are not detected at all as long as the printer can print.
The rest of the problems eventually cause a complete fail of printing, even if they are not indicated and printing is occurring normally. The first job in the Windows printer queue errors out and the rest of the print jobs stay in the queue as long as the problem is not fixed. If the number of jobs pending in the Windows printer queue exceeds a certain limit, the job status in transaction SP01 becomes unreliable. The number of job IDs returned to the SAP system in a status request call is limited to 1,000. If a larger number of print jobs stays in the problem status instead of printing or if they are in the error status in transaction SP01, you should take a look at the print server.
The following are some typical problem descriptions and questions that have been reported to SAP Support.
Q: The SAPSprint service does not start. It fails immediately.
A: Look in the sapsprint.dbg file. You may see one of two error messages:
- Error: The TCP port (515) for SAPSprint is in use
- Error: TCP/IP communication could not be started - aborting
If you receive one of these messages, then another program is listening on the specified LPDPort. Stop the program or change the port for SAPSprint. If two programs listen on the same port, the result is unpredictable.
Q: The SAPSprint service does not start. It fails after a long time with an error message on the Windows Service Control Manager.
A: Look in the sapsprint.dbg file. If you see a large list of installed printers at the beginning of the file that is suddenly interrupted without any further log messages, the detection of the installed printers lasts too long. If a service is not started within a certain time frame, the Windows Service Control Manager interrupts it.
Check to see if some of the installed printers are unavailable. If this is not the case, set the NoPrinterLogging option, as described in my first article. This option prevents the list of installed printers to be logged. The number of installed printers might be too large. If there are no other issues, this is fine; otherwise, you should lower the number of installed printers and use an additional print server.
Q: The SAPSprint service a takes very long time to start.
A: Look in the sapsprint.dbg file. You may see many entries that have either of the following:
- Restoring job B200000128162_1 with 1 copies for printer HPLJ4050
- Restoring status 4 for job B200000128088_1
If you see either of these messages, then the job restore mechanism is taking a long time. A message like the first one indicates that a significant number of jobs were not processed before a restart. This might be due to a very high workload or any problem during job processing. You can prevent the job restore with the NoJobRestore option. (I described how to do this in my second article.) However, you should only use this option if the restart is taking too long because you lose any jobs not processed before the restart. You must resend them from transaction SP01.
If you see a message like the second message, the number of jobs without a status query from the SAP system was very large before the restart. This might be due to a very high workload, or the fact that status query was switched off for some printers in the SAP system. Make sure that the NoStatus option is set in this case.
Q: The number of files in the LogPath is growing steadily.
A: Look in the sapwin_*.log files. Does the message “Leave PrintSAPWINFile with return code xx” end with a return code greater than 0? Then a job processing error occurred for this job. Continue as described in the “Job Processing Errors” section.
If the return code is 0, ensure that KeepFile and LogLevel are set to the default level according to SAPSprint control options, as described in my second article. Old log files can always be deleted without harm.
Q: SAPSprint seems to be consuming too many system resources.
A: One permanent working thread is generated per defined printer. If you have many defined printers, it can result in many permanent threads. You can change this with the ProcessingMode option, as I described in my second article. However, if you use this option, the job sequence is not guaranteed because no job queue is available. If you need the job sequence, you must reduce the number of installed printers and define a second SAPSprint print server.
Q: Printing on some printers causes problems with SAPSprint using SAPWIN device types.
A: Printing with SAPSprint and SAPWIN has one crucial difference compared to any other application: SAPSprint is a long running service printing thousands of jobs, sometimes in parallel, during the process lifetime. Printing from any end-user application usually means printing a few documents during the process lifetime.
Many printer drivers were not intended to be used the way SAPSprint uses them. SAP has defined a test scenario where the same SAPWIN data stream can be sent any number of times to SAPSprint for processing and printing. The defined Windows printer only has a file port, so the result is printed to a file.
The important part of the test is the SAPWIN processing with the Windows GDI using the printer drivers. Using this scenario with printer drivers reported from companies shows that some drivers do not have a problem at all and they process jobs quickly. Some are slower, but finally process all jobs successfully. However, many drivers suddenly develop problems during job processing and the print job fails. Details on how to handle these problems are described in the “Job Processing Errors” section.
Q: Can I use printer-specific options with SAPSprint?
A: No, usually not. A limited exception is described in the next question. Printing from an end-user application offers a print dialog with printer-specific options. You can set these options in the printer dialog from the printer vendor. These dialog pages communicate directly with the printer driver. The options are not accessible via the Windows GDI. SAPSprint offers no end-user interaction, so you cannot use these options.
Q: SAP device types offer print controls to choose a paper tray. Can these print controls be used with SAPSprint and a SAPWIN device type?
A: Yes, in a limited way. The limitation is principally the same as in the last question. The trays are printer-specific and are usually accessed via a printer vendor page in a print dialog. However, the Windows GDI allows you to set the tray number.
To do this, you need an internal printer-specific tray ID. You can see this internal ID when calling sapsprint –o –p <printer name> from the command line. In the generated sapsprint.dbg file, you can see all settings for the specified printer, including the installed trays with the name and the internal ID.
This question comes up from time to time and finally the problem was solved with some trial and error. The only way to find the internal ID is to map a given tray number (e.g., 1) to the internal ID. The mapping is done by identifying the 1 within the name. Unfortunately, the name is not unique. It is language-dependent and not even guaranteed that the number appears within the name at all. Therefore the mapping might not work in any case. Furthermore, the mapping can only be done for the trays numbered one, two, and three. Any other physical trays — such as envelope — cannot be mapped to at all.
You can adjust the mapping by modifying the print controls TRY01, TRY02, and TRY03 in any SAPWIN device type. Make a copy of the SAPWIN device type in transaction SPAD and change the print controls as follows:
- If the device type does not contain the hex switch, then the TRY01, TRY02 and TRY03 print controls have the values T1, T2, and T3. Change them to y1, y2, and y3 accordingly. These values are interpreted from the SAPWIN interpreter in SAPSprint. With the y values, a new mechanism of tray selection within the SAPWIN interpreter is used. The old T values usually don’t work for most of the printers available because no mapping is done at all. This is case-sensitive, so make sure to change the upper-case T to a lower-case y. Figure A shows the print controls and the corresponding hex mode in transaction SPAD. Some print controls contain unreadable characters. That’s the reason why often the Hex mode is used to display the values.
- If the device type contains the hex switch, then the value is the same as before, but hex-coded. For example, 54 is the hex coding for T, so change the 54 to 79, which is the hex coding for y. Leave anything else as it is and save the changed device type.
Figure A
Unchanged print controls
Michael Szardenings
Michael Szardenings is a senior developer in the SAP IMS organization. Working in the Systems Management Group within IMS, Michael is responsible for all kinds of Windows printing from SAP systems. He started his career in 1989 in the IBM Research and Development Lab in Germany, with the development of various user interface components for IBM mainframe computers. As SAP IBM came together on several joint venture projects in the systems management area, which includes job scheduling and printing, Michael’s focuses switched to SAP. He joined SAP in 2001.
You may contact the author at editor@sappro.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.
Premium
