SupPOUpdate job - who/what is scheduling this?

Question

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

Answer 1

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.