Debug a Complete Background Job
The Programs which typically consume a lot of time for execution are utilized for scheduling in the background (Batch) as while executing these online the system gives a timeout message & parallelly the developers are not required to wait for it got completed. The background jobs are created in standard transaction SM36 & the status can also be viewed in Standard Transaction SM37 such as released, ready, scheduled, finished, active and Cancelled.
All the Background jobs which have a status of "Finished” & “Cancelled" can be debugged. Incase you are debugging a job which has already been completed job, (a copy of it) then the same will be re-executed and any state changes or databases would again be made to them. This would be quite risky if the user is doing this in PRD. Besides this, If the program runs on the basis of the selection status which had been previously altered, it may not get executed in a similar manner the way it was done previously.
There are three options to debug a background job:
Option 1) Choose a job in transaction SM37. In addition, setting up a breakpoint at the point in the source code which you want to analyze when debugging. In SM37, enter JDBG in the OK code field, and press ENTER. The selected job is now started in debug mode, and the debugger initially stops in a system program. Choose F8 for continuing the job up to the next breakpoint.
Note: Although the job still appears in SM37 in the previous status after debugging, the entire job (or, more specifically, a copy of it) has run during debugging and possible database changes are effective because of this job.
Option 2) By using SM37 (Catch active job) or SM50 (Debug program), the user can catch a current background job. For doing this, the user should be logged on to the instance on which the job is running. The job is then stopped, and a user can continue running it in the debugger.
Option 3) Use SM36 for creating a job with two steps, step 1 with the BTCLOOP report and step 2 with the report to be debugged. Then, setting up a breakpoint in the step 2 report and releasing the job.
A user can also debug the job in transaction SM50. For doing this, the user should exit the endless loop in the BTCLOOP report by changing the variable i.
Note: Most of the times debugging is performed for cancelled jobs for finding out the reason why it failed or cancelled, It also maybe because of instinct how my program will be executed successfully.