SupPOUpdate job - who/what is scheduling this?

[Former Member]

Hi

We have a job running in our ECC Production system which we can see through SM37 which is failing. The job's name is SupPOUpdate, which is odd as lower case is not actually supported and if we try searching for that job name it can't find it, unless we look for SPOU for example. The job does not appear to be scheduled directly in SAP; there is no 'scheduled' or 'released' jobs in the future yet it runs every day.

We need to cancel it; it runs a Z program which is already scheduled anyway. However, how do you cancel a job that is not scheduled or release anywhere?

It looks as if something else is scheduling this job - but what? It's not Redwood CPS (we do have this but nothing is currently set up in Production). Our PI/XI expert insists that this isn't a job from there.

Any ideas?

Thanks

Ross

[Former Member · Accepted solution]

You could try executing a function module like BAPI_XBP_JOB_DELETE which requires the JOB ID, not the name, as input.

Alternatively, you could try renaming the job by modifying it's entry in table TBTCO with a database UPDATE statement (eg: just change the JOBNAME column value to all-capital letters). Then see if you can select it in SM37 and delete it or unschedule it.

Cheers,

David.

[Former Member · Accepted solution]

Hi David

Many thanks for your response, some useful things there. However, I can actually display the job in SM37 anyway by selecting for jobs unsing asterisks where the lower case letters are, and it is shown - but only previous runs. I cannot find a 'scheduled' or 'released' job for the next day; yet, the next day, it has ran. And you can't cancel a job that has already ran.

So I can see the jobs that have already ran in TBTCO - but not the next one about to run, so again, can't cancel. Simararily, I can't get the job ID of the next job to run in order to be able to delete it with BAPI_XBP_JOB_DELETE....

Ross

[Former Member · Accepted solution]

Oh sorry, my misunderstanding!

The job must be coming from somewhere, and not from someone that logged in to the system, since the job name has lowercase letters.

My first question would be this - is it running at the same time every day? (or whatever frequency it runs) If so, I would turn on gateway tracing via SMGW.

goto -> trace -> gateway -> increase level

when the job runs, then change it back

goto -> trace -> gateway -> decrease level

Don't leave tracing on any longer than is necessary, because it generates a LOT of logging!

When you look at the trace file with

goto -> trace -> gateway -> display file

you should see an RFC call to kick off the job. I think it's RFC_ABAP_INSTALL_AND_RUN that a job scheduler would use, but I could be wrong on that - still, look through the file, and you should see something that jumps out at you.

Here's an example, I just executed the RFC_READ_TABLE function module from a remote machine, and my gateway trace file shows this:

--------------------------------------------------------------------------------
| Address   | Offset | CPIC-Data                                               |
--------------------------------------------------------------------------------
| x10920c10 | 000000 | 05020000 0502000b 00063700 31003100 |  ..........7.1.1. |
| x10920c20 | 000016 | 000b0102 001c5200 46004300 5f005200 |  ......R.F.C._.R. |
| x10920c30 | 000032 | 45004100 44005f00 54004100 42004c00 |  E.A.D._.T.A.B.L. |
| x10920c40 | 000048 | 45000102 03370000 03370512 00000512 |  E....7...7...... |
--------------------------------------------------------------------------------

Of course, my hostname, logon name, etc is all in there as well - so there's plenty that should help you nail down where this is coming from.

[Former Member · Accepted solution]

Sorry - had to split this into two posts, or the code tags would not work.

If you still can't verify it with the suggestion above, try turning up the trace level 2 times, and check again. Doing this, I not only see that the RFC_READ_TABLE function module was executed, I also see a hex dump of all the parameters sent along with it (eg: RFC_READ_TABLE was used to read table TBTCO, and all the fields specified). Looks like this (and there are hundreds more lines I had to truncate):

--------------------------------------------------------------------------------
| Address   | Offset | CPIC-Data                                               |
--------------------------------------------------------------------------------
| x10920470 | 000000 | 05020000 0502000b 00063700 31003100 |  ..........7.1.1. |
| x10920480 | 000016 | 000b0102 001c5200 46004300 5f005200 |  ......R.F.C._.R. |
| x10920490 | 000032 | 45004100 44005f00 54004100 42004c00 |  E.A.D._.T.A.B.L. |
| x109204a0 | 000048 | 45000102 03370000 03370512 00000512 |  E....7...7...... |
| x109204b0 | 000064 | 02050008 44004100 54004100 02050205 |  ....D.A.T.A..... |
| x109204c0 | 000080 | 000c4600 49004500 4c004400 53000205 |  ..F.I.E.L.D.S... |
| x109204d0 | 000096 | 0205000e 4f005000 54004900 4f004e00 |  ....O.P.T.I.O.N. |
| x109204e0 | 000112 | 53000205 02010012 44004500 4c004900 |  S.......D.E.L.I. |
| x109204f0 | 000128 | 4d004900 54004500 52000201 02030002 |  M.I.T.E.R....... |
| x10920500 | 000144 | 3b000203 02010016 51005500 45005200 |  ;.......Q.U.E.R. |
| x10920510 | 000160 | 59005f00 54004100 42004c00 45000201 |  Y._.T.A.B.L.E... |
| x10920520 | 000176 | 0203003c 54004200 54004300 4f002000 |  ...<T.B.T.C.O. . |
| x109205a0 | 000304 | 20002000 20002000 20002000 20002000 |   . . . . . . . . |
| x10920560 | 000240 | 02030301 000c4600 49004500 4c004400 |  ......F.I.E.L.D. |
| x10920570 | 000256 | 53000301 03020008 000000ce 00000010 |  S............... |
| x10920580 | 000272 | 03020303 00ce4a00 4f004200 4e004100 |  ......J.O.B.N.A. |
| x10920590 | 000288 | 4d004500 20002000 20002000 20002000 |  M.E. . . . . . . |

With tracing two levels up, you should see not only the RFC to kick off the job, but also the job name. In fact, if you can narrow the tracing time down to a very short period of time, you might try the 2x option first. Just make sure to turn it back down. The difference in logging size from 1x to 2x is tremendous.

Hope that helps

Cheers,

David.

[Former Member · Accepted solution]

Hi David

Thanks for this. The job is running at 9PM each night so I will dial in one night this week if I get chance and enable/disable the trace as suggested.

Odd.... it's not running every single night, but seems to be intermittent... perhaps the calling job (wherever it is) failed those times.

Susankar, thanks for your reply, but already tried this. The job is not manually scheduled in the SAP system.

Cheers

Ross

[Former Member · Accepted solution]

Thanks but even increasing the trace level twice I cannot see what is triggering this job. I have spent several days re-scanning and searching the trace file (huge) but cannot see anything related to ABAP RUN/INSTALL etc or the job name; nothing is jumping out at me at all.

Any other ideas anyone?

[Former Member · Accepted solution]

Now resolved - it turned out that the ABAP code was calling another function in certain circumstances, which in turn, fired off a batch job.

[manu_susankar]

Hi Ross,

Did you try to check scheduled/released job in SM37with a one year date range like <one year before> current date <one year advance> ? You can check even with high intervals of date range, I hope you will get with this.....

Regards,

S.Manu