1054561 - Output sequence is lost when you use SAPSprint

Symptom
When you use SAPSprint on a print server, the system may not output requests in the required sequence.


Other Terms
SAPSPrint, sequence, 'Process requests sequentially', sorting


Reason and Prerequisites
First, make sure that indicator 'Process requests sequentially' is set for the output device in transaction SPAD. This is the basic prerequisite to ensure that the requests leave the SAP system in the correct order.

When you process the print request in SAPSprint, the sequence may be lost in various places. This is not normally the case. However, this may occur in rare cases due to the design of SAPSprint. The reason for this is parallel processing and receiving print requests in different operating system threads. A task that was started later in a separate thread may end earlier than a task that was started earlier in a different thread. The threads 'overtake' each other.


Solution

Two parameters are available to adjust the behavior. However, both use serialization to slow down processing of print requests. Therefore, you should change the default behavior only if the sequence is relevant and if the sequence problem occurs.

Both parameters are provided on the 'SAPSprint Processing' page of the option editor (see Note 85469). First, select the 'Enforce serialization' option. If you use this option in the internal processing queue, the system retains the sequence by blocking a print job that was received later until a job that was received earlier has been placed in the queue.

If the sequence problem still occurs after this, deselect the 'Use separate thread for job reception' option. This ensures that the complete print job is received by one single thread. Overtaking can no longer occur during reception. However, this causes reception to be restricted to one single thread. This may cause reception problems for large print jobs because the thread is blocked for too long. Therefore, you should set this option only if it is absolutely necessary.

No comments: