SAP Note


  924840 - A background job unexpectedly runs for a long time
Version   7     Validity: 12.07.2013 - active  


Language   English

Header Data
Released On
Release Status

12.07.2013 13:04:38
Released for Customer
BC-CCM-BTC Background Processing

Other Components BC-ABA-LA Syntax, Compiler, Runtime

Recommendations / Additional Info

A background job unexpectedly runs for a long time. However, this is not a global performance
problem in background processing, but rather the problem occurs sporadically or for certain jobs

Other Terms
Long runtime, performance, background, background job

Reason and Prerequisites
The symptom described above is not an error in background processing.
All known reasons for the problem are listed below:
1. The report that is executed in the background job tries to establish a connection to the GUI.
For example, the system tries to display a selection screen or a dialog box. However, this does
not work in the background. Depending on how the report or the GUI technology used are
configured, the report tries to establish a connection to the GUI after each failed attempt. As
a result, the report hangs in an endless loop.
2. It appears as if the background job was still running, but it has terminated. Note that the
job status displayed in SM37 or delivered by all programming interfaces is always the job status
that is defined in the database.
              Ideally, this job status should represent the actual status of the job. However, in
rare cases, jobs may terminate and the job status can no longer be updated in the database, for
example, due to a temporary loss of the database connection.
              In this case, the job status in SM37 is still displayed as 'active', even though the
job is no longer running.
              If you suspect that this is the case, select the job in transaction SM37 and choose
'Job -> check status' in the menu.
              The job status from the database is compared with the actual job status and set to
'terminated' if required. In this case, the problem has to be analyzed like a job termination.
(Analyze job log, Syslog. Developer Trace)

The following section specifies how you should proceed to analyze the problem if none of the reasons
specified above caused the problem:
The problem must first be checked by colleagues who are responsible for the component to which the
program that is experiencing long runtimes belongs. First, the problem must be isolated. In other
words, the source code segments in which the program runs for a long time must be found.
Consider the following points:
- Is the problem related to the volume of data being processed by the program? The runtime of a
program does not necessarily have to increase linearly with the volume of data, but can also
increase exponentially (depending on the programming, the system resources and so on).
If there is a connection between these factors, check whether the problem can be solved by parallel
processing or by dividing the work packages.
- If you do not know the volume of data that the program is processing, check the statistics in
transaction ST03N.
Also, a program designed to be executed in the background should always write suitable progress
confirmations to the job log (using the ABAP command MESSAGE). The job log messages automatically
receive a time stamp.
- Other analysis methods:
a) Debug the background job (transaction SM50).

Select work process in transaction SM50. b) Execute a runtime analysis (transaction SE30). Go to the menu and select: Program/Mode -> Program -> Debugging Depending on which source code is being processed in the job. . this method does not always work. Validity This document is not restricted to a software component or software component version .Proceed as follows: . check the job details to determine on which server and in which work process the job is carried out. because the debugger cannot access the source code at every point.In transaction SM37.