source:http://learnabapprogramming.blogspot.com/2011/05/how-to-debug-background-job.html
Usually,the programs which take long time for execution are scheduled for background job.Again,one need not wait for the completion of same.We use to create the background jobs in standard transaction SM36 & can view their status in Standard Transaction SM37 like Scheduled, Released, Ready, Active, Finished and Cancelled.
Background jobs with status "Finished” & “Cancelled" could be debugged. If you are debugging an already completed job, it (a copy of it) will be re-executed and any databases or state changes will again be made to the database. This could be fatal if you are doing in a live environment(Production systems).Another point to be noted is that,the program may not get executed in the same way that it was done last, in case the program runs based on selection status that was altered by last run already.
Now what are ways by which we can debug program while its in background?
Well,there are three options or ways we can tackle this.
1)Select a job in transaction SM37. In addition, set a breakpoint at the point in the source code that you want to analyze when debugging. The debugging could be a hard brak point or a sesssional breakpoint.Now in SM37, enter JDBG in the OK code field, and choose ENTER. The selected job is now started in debug mode, and the debugger initially stops in a system program. Choose F8 to continue the job up to the next breakpoint.This is one of the best options available.
I would like to caution you that,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 as a result of the job.So make sure you check in that perspective too.
2)You can catch a current background job by using SM37 (Catch active job) or SM50 (Debug program). To do this, you must be logged on to the instance on which the job is running. You need to check the server details of the batchjob and then try this method.The job is then stopped, and you can keep it running in the debugger.This method is really helpful for live batch jobs.
3)Use SM36 to create a job with two steps, step 1 with the BTCLOOP report and step 2 with the report to be debugged. Then, set a breakpoint in the step 2 report and release the job.This is particularly useful when you are dealing with standard reports/programs or if you don't want to touch the code of the program.
You can then debug the job in transaction SM50. To do this, exit the endless loop in the BTCLOOP report by changing the variable i
Usually,the programs which take long time for execution are scheduled for background job.Again,one need not wait for the completion of same.We use to create the background jobs in standard transaction SM36 & can view their status in Standard Transaction SM37 like Scheduled, Released, Ready, Active, Finished and Cancelled.
Background jobs with status "Finished” & “Cancelled" could be debugged. If you are debugging an already completed job, it (a copy of it) will be re-executed and any databases or state changes will again be made to the database. This could be fatal if you are doing in a live environment(Production systems).Another point to be noted is that,the program may not get executed in the same way that it was done last, in case the program runs based on selection status that was altered by last run already.
Now what are ways by which we can debug program while its in background?
Well,there are three options or ways we can tackle this.
1)Select a job in transaction SM37. In addition, set a breakpoint at the point in the source code that you want to analyze when debugging. The debugging could be a hard brak point or a sesssional breakpoint.Now in SM37, enter JDBG in the OK code field, and choose ENTER. The selected job is now started in debug mode, and the debugger initially stops in a system program. Choose F8 to continue the job up to the next breakpoint.This is one of the best options available.
I would like to caution you that,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 as a result of the job.So make sure you check in that perspective too.
2)You can catch a current background job by using SM37 (Catch active job) or SM50 (Debug program). To do this, you must be logged on to the instance on which the job is running. You need to check the server details of the batchjob and then try this method.The job is then stopped, and you can keep it running in the debugger.This method is really helpful for live batch jobs.
3)Use SM36 to create a job with two steps, step 1 with the BTCLOOP report and step 2 with the report to be debugged. Then, set a breakpoint in the step 2 report and release the job.This is particularly useful when you are dealing with standard reports/programs or if you don't want to touch the code of the program.
You can then debug the job in transaction SM50. To do this, exit the endless loop in the BTCLOOP report by changing the variable i