job spool error after system copy (device type does not match device)

[marie_renneke]

Hi experts,

I'm not sure if it's a spool or a job problem - but because the error message points at problems with spool requests I opened this discussion in "Output Management".

After system copies in one system landscape we face the problem that the spool requests of one special job (some kind of Z-program) is getting corrupted somehow - this hasn't always been that way - it happened for the last 5-6 copies.

The job runs for some time and aborts then - the job log contains the error message "Device type HP4250 for request 24.853 does not match current device" where HP4250 is the (correct) device type for the printer of spool number 24853.

When you delete that spool request and restart the job it aborts at the next spool number that was created in the first job execution.

Only if you delete all spool requests that were created during the first aborted job execution the job can run again with the same parameters like before (same printer, same program, same device type...) .

Of course we reorganize the spool after system copies (RSPO1041) and clean up inconsistencies (SP12).

And for this is affecting only one job it doesn't seem to be a general problem.

Usually that happens right after the system copy and with the first execution of that job - weird enough. But today it occurred 1,5 weeks after the system copy and after several successful job executions which seems even stranger.

I couldn't find anything concerning this error message via SAP Marketplace or anywhere else.

Has anyone of you ever faced a problem like this? Could you find a solution to it?

Many thanks and best wishes

Marie

[alexander_bolloni · Accepted solution]

Hello Marie,

I tried to find out where this message is raised. I believe it is message PO 465 which gets raised from function modules RSPO_SR_ADD_PARTS or RSPO_SR_SET_PARTS_SPOOLJOB.

This relates to a rather obscure functionality of the spooler where a program can construct a "composite spool request" from a set of "normal" spool requests. You then have a "father" spool request which does not really have content but contains only references to other, "child" spool requests (ABAP lists, SAPscript/Smart Forms).

I assume your Zxxx program makes use of this functionality.

Since a "composite" spool request can be printed to the printer associated with the father request (which means, printing all children in sequence to that printer), it is obvious that all "children" requests must be created for a printer with the same device type (not necessarily for the same printer, but the device types of children and father must match!)  as the father's printer.

The message now is raised when during one of the above function calls (which you should be able to find in the custom program) it is found that the printer which the child request was created for has a different device type than the printer for which the father request is created (HP4250 is the device type of the child request, and 4853 is a child request which the program tries to add to the father - we don't know which printer or device type is used for the father).

So it seems the program is creating a father request for the "wrong" printer whose device type does not match those of the children... It is definitely a good idea to involve the DEV team responsible for the program.

Best regards,

  Alexander

[marie_renneke · Accepted solution]

Hi Alexander,

thank you for this detailed response! I forwarded your message to our customer - they want to get the program rechecked now by the developers. Looking forward to get feedback the next weeks.

As soon as there are any news I'll update this discussion.

To everybody thanks so far for all your ideas!!!

Best wishes

Marie

[Former Member · Accepted solution]

Hi Marie,

Any news from your dev team?

Cheers

Cyril

[Former Member]

Hi Marie,

Not sure about the root cause but there are two weird things about your issue. The one that makes me think that you may have an inconsistency problem is revealed by the fact that it appeared a few weeks after your copy.

You wrote that you've reorganized the spool after the system copy, but according to note 16083,

RSPO1041 must run everyday: can you please make sure that this job is running daily? If yes, is there anything abnormal in the logs?

You didn't mentionned if this specific job was running in your original system. According to your description, i guess the issue appears in the target system?

Apart the fact that you may need the spool, can you run this program in dialog mode?

As it is a specific program, i would suggest you to ask your DEV team: maybe they can find some hints in debug mode.

Hope it helps

Cheers

Cyril

[bxiv]

Can you find anything that is in the same time frame of the spool issue with ST22 or SM21 that might also provide some additional information?

Perhaps you have two memory intensive jobs that are conflicting with one another, which is only showing as a problem in the target system due to less resources being available; as an oddball off the wall thought.

[marie_renneke]

Hi Cyril, hi Billy,

first of all thanks for the quick responses.

• RSPO1041 is running daily without any problems - there are no errors logged by that reorg job. It's executed with a variant that is deleting spools older than 10-15 days (depending on the status) or spools that are obsolete - none of that conditions match with that application job during execution time - also the reorg job ran hours later...
• as you assumed the problematical job is running in the target (QAS) system. It's always planned freshly after the system copy and is not taken over from the productive system. A similar job is running on the productive system - same program, different variant. There it never faced any problems like this.
• dialog mode / development team: I will ask our customer to do so. I'm also afraid it's a general problem with that one program but I wonder why this problem does only occur in the QAS system and only after system copies... so I'd really like to eliminate possible administrative problems beforehand
• unfortunately there are no messages in SM21 or dumps in ST22 at that time - I couldn't find out in which workprocess the job was active so nothing to help here either...
  Hence I couldn't find memory bottlenecks or the like at execution time... ST02 looks good, too (except some experiments that once filled EM, heap and PageArea - but not during that job execution)  .... hadn't checked memory before so thanks for that idea anyway

There are several things confusing about this situation.

First of all this job is usually able to run properly - it did in QAS and does it again now - and it still does in PRD. Second is that we've faced this problem for some copies now - but it hasn't always been that way - so I'm not sure when exactly the problem started but last year we patched the whole system (SPs, kernel, DB) - I'm a bit worried that we caught some kind of bug here...

Do you have any other ideas? Or maybe similar experience?

Thanks again

Best

Marie

[bxiv]

Do you have a way to track down associated transports to this program?  I could see this being a hard coded SID based on a unique condition that perhaps is only triggered on rare occasions end of a month, financials ending/opening.

Is this scheduled via sm36/sm37 or a third party tool (Redwood/Tidal/etc)?

And am I reading your comment correctly, this job was setup from scratch after the system copy or modified to work in QAS?

[marie_renneke]

Jobs are scheduled via the usual SAP tools and not through a third party tool.

To be sure how the job is created I asked the customer again - the job is already existing in the source system with its name, variants etc. but it's not running there - it's planned.

They just go ahead and release the job in the target system after the copy so they don't have to create it from scratch every time we do a system copy because it has quite a lot of steps.

Does this information change anything?

[bxiv]

So in Prod there are 2 jobs that exist that perform the same functions however one is set to a state of 'scheduled' vs 'released' and the only purose is to avoid a setup of the job in the target system during refreshes...for a side note this screams for a 3rd party tool.

Is the Production job still in your target system?  I could see someone being logged into multiple Prod/QA systems at the same time and without verifying see the job is not released and go through the process of having it run?  Is SM36/SM37 wide open to all users or locked down to specific ones?

Also odd question, how are printers managed in the system?  PAL/transports/export & imports?

[marie_renneke]

Hi again,

yap - that's exactly how it's done in this case - unfortunately I'm not the one to decide about job scheduling tools

The production job still exists in the target system in status planned - and hasn't been started by anyone - it's still planned and no job logs can be found concerning this job or the like (I know logs can be deleted but that's the only way for us to prove it). I can understand this assumption and surely can't remove all doubts a hundred per cent but only a handful of people are working in the QAS system so I guess this shouldn't be the problem.

They seldomly create printers and aren't really sure how they did the last times - but they used either export/import or created the printer directly in each system (I guess it's the first method). PAL and transports were definetly not used.

The printer we're talking about is exactly the same in PRD (sure for it has just been copied ) and it's the same printer as used in the production job. It works with host spool access method E via our print server like all printers in this system landscape (except LOCL or the like).

Does that help you anyhow?