In some exceptional case, we may need to analyze the program scheduled as background job in non -development systems. We can accomplish this using below ways.

  • JDBG (Job debugger)
  • Debugging the work process in SM51
  • If the job ends immediately before reaching SM51, adding endless loop in the code and debug the work process from SM51

The idea of this document is to share the other available approach in debugging the background job.

When a completed job is debugged using JDBG, system creates a copy of the entire job and it is re-run during debugging. The database changes can be possible as a result of debugging using JDBG. So I would like to analyze the job before it completes.

If you are used to analyze the background job using work process debug, then you may need to note down the application server & work process in which the job is run. In many cases, the job might get executed before we reach/spot the work process in SM51.

How to handle such cases in non- development system:

What if you need to analyze a standard / custom program in non-development system which is run in background & it completes instantaneously on scheduling. You will not be able to add Endless loop in the code in such cases.

  • Using BTCLOOP Report:

If you have Edit authorization in debugging, then you can follow the below steps.

Schedule the report BTCLOOP as a step 1, followed by the program which you need to analyze.

The program BTCLOOP has an endless loop and the work process will be executing this code. We can identify the work process without any rush and debug by selecting the workprocess and clicking on Administration->Program->Debugging

/wp-content/uploads/2016/01/btc_874880.png

In the debugger, exit the loop and F8 would stop the debugger at the external breakpoint which you have set in the program to be analyzed.

  • Using RSWAITSEC Report

If you don’t have Edit authorization in debugging, then you can schedule the report RSWAITSEC instead of BTCLOOP. If you have set 20 in this report, the nworkprocess will be waiting for 20 seconds. In the meantime, you can reach the workprocess in SM50. After the wait time ends, the debugger will start and you can proceed your analysis from there.

/wp-content/uploads/2016/01/wait_874881.png

If you have used other effective ways to handle such similar cases, please share it here.

With Regards,

Karthikeyan

To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

    1. karthikeyan P Post author

      Hi Eitan,

      Thanks,

      We had a scenario in production system where some IDOCs couldn’t be processed but terminated with short dump. We couldn’t observe the same when we processed that in foreground.

      I had to debug RBDAPP01 in background mode and the above programs were handy.

      Thanks,

      Karthikeyan

      (0) 
      1. Eitan Rosenberg

        Hi Karthikeyan ,

        Sure thing.

        The mere fact that in the last 10 years I did not had to debug background jobs dose not mean that I will no have to do it in the next 994 days.

        Regards.

        (0) 

Leave a Reply