Additional Blogs by Members
Showing results for 
Search instead for 
Did you mean: 
Active Contributor

When we last saw the ABAP Detective episode [ The ABAP Detective Queues Up ] the facts of the case led me to an impasse.  I had searched for "printers that have died" and came away with a piece of table. TSP03 is the short answer; a longer view follows.

I needed to figure out where the indications of dead devices appeared.  On one hand, spool devices are defined in SAP; on the other hand, I found most of the working queues went to Unix (AIX to be specific).  At the OS level, UNIX systems support one of several legacy protocols (lp, lpr), and the evolved version of one of them. In AIX, printcap is spelled qconfig.


rembak[21233682] main: Fri Apr 22 09:05:23 2016

rembak[21233682] main: /usr/lib/lpd/rembak -T90 -D /tmp/MX08.debug -S printer2 -P TEXT -N /usr/lib/lpd/bsdshort -o -d -o p -o -X -o 850 /var/spool/qdaemon/tTzo7aa

rembak[21233682] main: backend=1.

rembak[21233682] hookup: (FATAL ERROR) Unknown host printer2.


Reading the evidence, one of the print spool log files showed a fatal error (capitalized for effect), spinning a strange tale of a print job that ran but could not locate the target device.  The failure was not communicated back to the batch job, apparently.  It was my assignment to find out why, or at least what.

The coroner confirmation of defunct device destination:

$ nslookup printer2

** server can't find printer2: NXDOMAIN

In my skeleton key privilege collection, I could not access the transaction showing dialog process logs, which made finding the connection trickier.  I did have shell access (hence this post in the SAP on UNIX  space), and was able to take a gander at the logs in the usual sub dir.

$ grep -l MX08 * 2>/dev/null


As the protagonist printer was revealed in one case file, I browsed it a little deeper with the text analysis tools at hand.  You know the type, cat and friends.  Inside was nothing to write home about, much less wrap up a case, but it was something.  The small fragment:

M  ThInit: initializing SPO work process W53


S Tue Apr 19 17:12:14 2016

S  1 pages (List) printed in 0 seconds, avg. 0.0 pages per sec

S  Timeinfo @>SPOREQ:703853@</1 (@>DEV:MX08@<): 0 1 List ( 0 0 0 0 0 0 )

S  1 pages (List) printed in 0 seconds, avg. 0.0 pages per sec

S  Timeinfo @>SPOREQ:703854@</1 (@>DEV:MX08@<): 0 1 List ( 0 0 0 0 0 0 )


Obligatory process status list:

02_____01 54  SPO  18415666 Running        Yes            47 SAPSYS  querying
03_____01 53  SPO  18153514 Running        Yes            39 SAPSYS  querying

So SAP handed over the goods to AIX, which responded affirmatively, at least that's how it looks.  One page per process ID.  I needed to find that spool 703854.

Climbing out of the ssh access tunnel, I went back through the frontend gateway, also known as the SAP GUI.  After some back and forth, my magnifying glass (or binoculars) scanned into the spool list, and bingo, there was old '54.

Inside the spool view, I needed to be careful and not touch any evidence, as spindling or mutilating the pseudo-paper would be frowned upon.  Flushing the evidence down the bit bucket has caused more than one investigation to hit signal 9.  What I could see was a single page output.  Everything checked out as the place to find where these bits were formed.  But, what next?  The calling program was not obvious (even before redaction).

Text version of the above (for SEO):

  Spool no.  Type User name DateTime  Status Pages Title

703854_______ 04/19/2016 17:12 Proc.1  ______ MX08 Z__________H

Yes, SM37.  I can get there.

Once in SM37, I found the job that triggered the print spool request.  This still doesn't show the actual code, but it's getting closer.

04/19/2016 17:12:09 Step 004 started (program Z____, variant ___PRNS, user ID ____)  00550S
04/19/2016 17:12:13 Job finished                                                                00517S

No. Program name/commandProg. typeSpool list Parameters  User Lang
1 Z..       
ABAP      703828 D_PRNS . EN
ABAP703840 O_PRNS . EN
ABAP      703851 C_PRNS . EN
ABAP      703862 M_PRNS . EN

Variant?  Is that a car model?

After casing the streets and alleys for a link from the spool log to the code, it finally showed up as an oft-maligned "go-to" menu pick.

"Goto Program" indeed.  The ABAP dates back to the previous century.  One small code quote:


                                          DEFAULT 'DEFT'.



The printer destination is in a variant, with several being triggered across the steps:

DO 11 TIMES.  " 4 Regulars, 5 M... Records, 1 C... copies

              " 1 DRT

So, to wrap up, what has been found and what's not?


  • Dead device indication in the UNIX print spool log file showing output attempts.
  • SAP spool process trace file shows no fault or error warning.
  • SAP batch job succeeds.
  • Connection found from UNIX spool log to SAP spool log, with a jump to the responsible code.


  • Turned-off or offline devices not visible inside SAP.
  • Is the report actually necessary, given lack of delivery?
  • full spectrum analysis; found print devices stored in variants (hard to search on)

In other sides of this case, I'm rifling the active directory files on cross over ideas, not to mention RFCs and SAP notes.  Details below.  Stay tuned for the next installment.

Notes / Docs

(Tool to analyze processing delays)

Planning the SAP Print Architecture - SAP Printing Guide (BC-CCM-PRN) - SAP Library

Forum / wiki posts

How to monitor and maintain printing via UNIX - Basis Corner - SCN Wiki

Spool Requests

SAP Spool Output Requests


RFC 2707 - Job MonitoringMIB - V1.0

RFC 3712 - Lightweight Directory Access Protocol (LDAP): Schema for Printer Services

RFC 3805 - Printer MIB v2

RFC 7612 - Lightweight Directory Access Protocol (LDAP): Schema for Printer Services


Prior Cases