Debug Background Job with Ease

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

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.

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

With Regards,

Karthikeyan