The ABAP Detective and the Deprecated Device
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 dev_w53 |
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 ) S |
Obligatory process status list:
|
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):
|
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.
|
|
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:
|
PARAMETERS : P_PRIN11 LIKE PRI_PARAMS-PDEST MATCHCODE OBJECT PRIN DEFAULT ‘DEFT’. SELECTION-SCREEN COMMENT 65(1) TEXT-010. PARAMETERS: P_PRIM11 AS CHECKBOX DEFAULT ‘X’. |
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?
found
- 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.
missing
- 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
https://launchpad.support.sap.com/#/notes/1849558/E
(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
RFCs
RFC 2707 – Job MonitoringMIB – V1.0
RFC 3712 – Lightweight Directory Access Protocol (LDAP): Schema for Printer Services
RFC 7612 – Lightweight Directory Access Protocol (LDAP): Schema for Printer Services
e.g.
Prior Cases
- The ABAP Detective Queues Up
- The ABAP Detective And The Degraded Upgrade – PART 1
- The ABAP Detective And The Degraded Upgrade – PART 2
- Pssst, ABAP Detective, you got a second?
- The ABAP Detective Never Signals an Interrupt
- The ABAP Detective And The Degraded Upgrade – PART 3
- The ABAP Detective Meets The Watch Men
- The ABAP Detective on Missing Persons Patrol
Another great episode! Keep them coming!
Chris - one of the unfortunate side effects of my "clever" prose is that readers seem to enjoy the style more than they react to the issues I tackle. It would be nice to get replies about how others do queue maintenance. I guess the people doing that work aren't my audience. Or maybe no one is on cleanup, they're all writing shiny UX5s.
Oh I shudder when I read these blogs...I chased spool issues down LONGGGGG ago and vowed NEVER to go near anything related again! haha