It's been a long time since the last ABAP Detective post. I could explain, but that's not what pays the rent in this space. The customer is looking for easy street, cloud city, know what I mean? So I take the cases that come my way, work them, then bury them like last week's trends. What makes this case so different? Nothing really, just another bit of a byte in the world of the enterprise software capers.
It started out with a message about lost print jobs. Normally I don't like missing person capers, because there's often a simple explanation that comes out when I am prepared to go full out with the detective black bag. "Oops" they say, must have unplugged the wrong cable. Easy for them to say, hard for me to write home about. This was different, a string of missing bytes that ended up with the suggestion that I do a full search for the bad data. Or configuration as the case may be. When I started looking through the mug book of known printers, something looked crooked. Some of these devices weren't around any more. They weren't sent up the river, they just expired.
When I looked further, I realized printers and their respective queues had been added to the SAP systems, and to the respective operating system spool devices, for years, but no one was removing any. Time to clean house.
First I looked at the OS print queue definitions. In there are host names. Sometimes these get replaced. Sometimes the building they were in just doesn't belong to the syndicate any more. I use a handy sweep tool called fping that tells me in a hurry who's dead, who's wounded, and who's nominally still alive. With this list, I was able to report a smoking gun: many defined print queues just aren't valid. That would be the end of the tale, and there would be nothing of interest to an SAP administrator, except for the other shoe, which is, "which of these OS print queues have defined SAP printers connected to them?" And, naturally, "which SAP printers are orphaned with no OS target to use?" Ah, the plot thickens.
I delved into one site as a starting point. Many queues defined, some still apparently extant. I asked my Basis person (sorry, "Foundation" seems to be the new phrase...) who spilled the beans, "TSP03". Ah right, the old TEMSE fill em up and wring em out routines. What does it look like?
Though TSP03 and TSP03C are related, I began with the direct approach. Looking for some kind of status indicator, I dug into the skeleton with no key.
The PASTATUS looked promising, suggesting a "Printer process status" value. Different that the "Spool status message" etc. With this data gem, I went through the public records on SCN and found, well, not much. I'm not sure if the question does not come up very often, or if I'm looking at it from the wrong angle, but most of my searches were totally rebuffed, or yielded few clues.
On line help keys were no help, saying "No input help is available" or words to that effect.
Just 4 google ponits for the key word, with only one of those spot on to the question at hand. From 2007, to boot. That's a lot of years in this business. Still, printer lights don't change that often, I'd wager.
That forum post [ Is there any Function module to find out no. of printers connected to SAP . ] had a misleading title. Or more accurately, had my question embedded inside another question, "Do u know any FM which shows the status of the Printer...?" and the following helpful response:
in table TSP03 check field PASTATUS. It contains a hex value. Here is the explanation:
02 -> printer is disabled 04 -> printer not active 08 -> printer is active 10 -> printer is faulty |
Well, harumph. What base arithmetic is this? It's not Octal, as there are no eight digits there. It isn't exactly hexadecimal either, not with the 2, 4, 8, 10 sequence. Where was the 01 flag? So that left me puzzled. Searching gave me few clues ("few" meaning not many, not "several"!).
What I could see in an active system was the decimal value "32", which would have a HEX value of "20". That wasn't in the 2007 message thread, meaning either that message was incomplete at the time, or the values have expanded since then (personally I believe the latter).
How ?
Found code:
IF tsp03-pastatus = c_rspopdisabled OR [...] |
So, nothing for "c_rspopdisabled" either. From that code, I headed in another investigatory direction. I looked for uses of TSP03 in the SQL cache (sometimes the DBA hat just fits).
Bizarrely, the first hit [RSPOWP00] came up with an error I don't often hit when clicking "ABAP Source": "Communication error when accessing remote system ...: Program name is blank" . In other words, you can't see the code. But eventually one of the other programs led me to the include file. To the old C programmers, this is an H file, or maybe a #include. The header even says something along those lines (I'm assuming this doesn't break any copyrights, since it's a plain text extract for review purposes):
Hier sollen alle Konstanten gesammelt werden, welche Werte aus dem C-Coding wiederspiegeln. |
Google translate guessed this as:
Here all the constants are to be collected, reflect the values of the C-Coding. |
Another site, (se80.co.uk) had a different view, closer to the "header" style:
Constants in the Spool Which Must be Compared With the C Source |
Perhaps a shade too literal.
I've taken out pieces of the code, though on the se80 site you can find the above snippet intact. It should be on your ABAP system as well. It's pretty, well, basic.
What have I found? In my search for the "printers that have died" I found a code 32, which means "async processing." I don't think that answers the question, but at least I have the correct underlying table to base my future research.
) etc. These approaches did not solve the problem.
