Skip to Content
-1

Background job

Hi,

In my project they have configured a Autosys tool in which all the jobs have been scheduled. My basic question is i need to debug one of the SAP job which is scheduled there.

There are more than 100 jobs which runs in a hierarchy in that Autosys box. One job in this box is used to create material grid. It created a idocs for material grid creation.

I kept the external debugger in the Z function module in the process code and was waiting to stop, but it never did.

How to achieve this. Please help me.

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

3 Answers

  • Jul 06, 2017 at 12:09 PM

    This is the result of a simple search....

    Add comment
    10|10000 characters needed characters exceeded

    • Uwe,

      Debugging a background job id from AUTOSYS.

      Since i have the process code and a Z-FM for that outbound idoc, it will be difficult for me to get the pre-requisites to run that FM.

      Please let me know your thoughts

  • Jul 06, 2017 at 08:40 PM

    You simply can't debug background jobs as usually (it's not like HTTP, RFC, dialog, ...) Uwe told you to search and read the answers; they probably all say to run the job interactively with the okcode "jdbg" in SM37 (or even modify the code to add an endless loop). If it's not possible, could you tell us why you can't?

    You also have the possibility to intercept a given job based on criteria, so that they don't start (you can then run it with jdbg). Search more information about program INITXBP2, transaction CRIT.

    Add comment
    10|10000 characters needed characters exceeded

  • Jul 06, 2017 at 12:58 PM
    -1

    Siva,

    Debugging a background job in PRD is not advisable.

    Is this AUTOSYS tool configured to schedule the jobs even in Q for your testing ?

    If not,identify the job name and find out the pre-requisites for this job and simulate in Q manually.

    K.Kiran.

    Add comment
    10|10000 characters needed characters exceeded

    • Those are reasonable reasons. But I'm not sure I agree that they're obvious, and really they only apply to projects, not to operational support. The only risk from read-only debugging is timeouts and unexpected commits.

      Unless you know what particular circumstances of data are causing an issue, you can't replicate it in tests. To figure out the circumstances, unless you've a copy of production data in your test system, you have to debug. Once you know the circumstances, you can then start setting up tests.

      I'll compromise.

      Do not debug in the production instance of an OLTP system objects delivered in a recent or ongoing project, except as a last resort.

      I also suggest you invest in decent programmers if your current mob keep doing things incorrectly.