// // Escribe un comentario

Debug a Background Job

How to Debug a Background Job

Most of the times debugging is done for cancelled jobs to know the reason why it get failed or cancelled? And may be sometime because of instinct how my program get executed successfully.


The Programs which usually takes very long time for execution are used to schedule in background (Batch) as on executing it online it gives a system time out message & at the same time developers need not have to wait for its completion. 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. Could be very dangerous if you are doing this in PRD. Also it 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.

Please follow the following steps to debug the background job:

How can you debug a program that runs in the background?

Other terms

Background, job

Reason and Prerequisites

Information about troubleshooting


There are three options:

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. 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.
              Caution: 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.

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. The job is then stopped, and you can keep it running in the debugger.

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.

              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.


Publicar un comentario

Nota Importante: los comentarios son para agradecer, comentar o sugerir cambios (o hacer preguntas) sobre el artículo de arriba.

Para otras preguntas, por favor envíe su consulta aquí, es gratis!. Su consulta no molesta, le responderemos a la brevedad