1057255 - Jobs remain in status 'ready'

Symptom

A job remains in the 'ready' status for a long time.

Other Terms

ready, delay

Reason and Prerequisites

Background information:
If you work in the dialog, your dialog session is running on one (usually of several) application servers. The dialog application that you use is executed only from this application server.
For example, if you choose 'Save' in your dialog screen, the system sends a dialog request to a free dialog work process on this server (and no other server). The dialog work process that contains the request then executes the ABAP statements that are associated with this button (for example, a consistency check for the data that was entered and then saving the data in the database).
If no dialog work process is free on the server, the system places your dialog request in a queue. This is still the case, even if there are free dialog work processes on other application servers.
Since the system usually processes a dialog request in fractions of a second, it is not long until a work process becomes free on the server again and it is the turn of your dialog request.

You do not want this behavior in the background processing. It may even be fatal. The simple reason for this is that the runtime of background jobs is often many minutes or even hours.
If an application wants to start a background job (without a target server), and if no background work process is free on the server on which this application runs, the user will of course want to start the background job on any of the other servers that have free background work processes.
In technical terms, the background processing may be as follows:
1.  It must be able to  send background requests across the entire system and not just on the local server.
2.   In addition, before the background request is sent to a certain server, the background processing must be sure that there is a free background work process on this server. A request that has been sent once can no longer be redirected to another server.

In the past, there have been problems (particularly with point 2):
For example:
- Two applications want to start a background job on the same server at the same time.
- there is still a free background work process on the server.
- Since both applications want to start the job at the same time, both applications see that there is a free background work process on the server and they each send a background request to the server.
The system can start only one background job. The other background request remains in the queue on this server (in the same way as the dialog processing). The background job that belongs to this waiting request only starts when a background work process is again free on this server. This may take a very long time. The background remains in the status 'ready' for this time.

Therefore, a background job has the status 'ready' in the time between when you send the background request and when the relevant background job starts. This should usually only take fractions of a second, and, at the most, a few seconds.

The problem demonstrated by the above example was eliminated in 2003. However, due to various options for starting a background job (immediate start, time-based start, event start), in theory, a background job may hang with the status 'ready' in a certain scenario. In this scenario, various events start several jobs at the same time, or one event starts several jobs with different event parameters at the same time.

Solution

We now deliver a solution for the scenario that is mentioned above. This means that, even in this scenario, background jobs can no longer hang in the status 'ready'.
Implement the advance correction or import the relevant Support Package.
After you implement the solution, the event jobs may experience a slight delay if you start many event jobs at the same time. That is essential because, in order to exclude the problem that is mentioned above, you must serialize the job starts.
In any case, you can significantly reduce the average delay. To do this, set the profile parameter rdisp/btctime to 30 (the default value is 60) on all servers.
However, if you want to retain the old behavior, you can deactivate the corrections. To do this, use transaction SE16 to insert the following entry in the table BTCOPTIONS:

BTCOPTION = NEW_EVTSTART
VALUE1    = OFF
VALUE2    = <any comment>

Header Data

Released On	09.12.2008 12:12:41
Release Status	Released for Customer
Component	BC-CCM-BTC-RUN Runtime Environment for Background Processing
Priority	Correction with low priority
Category	Program error