[1] Question: How are background jobs distributed? Answer: Background jobs are not distributed.

On each instance with background work processes, the system regularly starts a report (rdisp/btctime) that selects and starts the jobs relevant for this instance. As a result, an individual instance can process all jobs because its background scheduler always runs before the other ones and selects the jobs for itself. You can change this by making a minor change to the value from default 60 to, for example, 59. Then the "preferred execution instance" changes after the background scheduler has performed a number of runs: For example: System with three background instances rdisp/btctime 59 60 61 10:20:55 10:20:53 X 10:20:20 10:21:54 10:21:53 X 10:21:21 10:22:53 10:22:53 X 10:22:22 10:23:52 X 10:23:53 10:23:23 10:24:51 X 10:24:53 10:24:24 .... "X" indicates the preferred scheduler. [2] Question: What are jobs in the status "Ready"? Answer: In the short time between job selection and transfer by the work process, the job is changed to the status "ready". As one of the first steps, the process changes the status to "active" when it has taken the job. If a problem occurs during the transfer, the process "forgets" that it has to execute a job. These jobs remain in the status "ready". This is corrected during the system start-up by the "Zombi cleanup" or in SM37 (Job --> Check status). If jobs frequently remain with the status "Ready", contact SAP Support and provide them with the system log and the trace files for the affected processes. [3] Question: The operation of the background processing system Answer: Some minor restrictions apply in background processing. There is no GUI connection when steps are processed in the background. As a result, all activities requiring an active connection cannot be executed (WS_DOWNLOAD, frontend print, check boxes, ... ). There are also differences in terms of the memory request. Since an interactive reaction is not possible, the "All or nothing" rule should apply, that is, if a job step terminates, the entire job is rolled back. However, this also means that a "COMMIT" is not called within the report, for example, because otherwise the ability to roll back a job is lost. The "COMMIT" is automatically created by the background processing system at the end of the processing. However, the absence of the user link also means that update terminations can no longer be reported directly to the user. To receive a defined status of the business data, you must adhere to the above principle. [4] Question: Definition of the background processing system Answer: SAP background processing is used to automate routine tasks and to optimize the use of your company's SAP computing resources. During background processing, you instruct the SAP system to execute programs for you. Using background processing, you can execute long-running or resource-intensive programs at times when the system has a light load. You can then instruct the system to execute reports and programs. No load is placed on your dialog modes, and reports running in the background are not subject to the runtime limits of the dialog modes. What is this actually called? The main emphasis is on the point "execute at times when the system has a light workload". The background processing system is not suitable for creating additional resources. It should take on tasks in the system for which a user is not absolutely necessary. [5] Question: How can I determine the throughput of the background processing system? Answer: The maximum throughput of the background processing system can only be determined as an approximate value. The influencing factors here are the total number of background processes, the value of the parameter rdisp/btctime, and the number of class "A" processes. If you ignore the fact that the jobs can have longer runtimes than the rdisp/btctime and the default value of this parameter is used, it is relatively simple to determine the throughput. For periodic jobs, you can determine the number of required work processes per minute. You will receive this figure if you divide the number of jobs with a certain period time by the period value in minutes. You then get a number of processes that is required as a minimum for handling of jobs with this period:

Example (rdisp/btctime=60): Number Period duration Calculation No. of WP 5 every minute 5/1 5 15 every 5 minutes 15 / 5 3 20 every 10 minutes 20 / 10 2 .... As you can see, at least 10 background processes are needed to process the periodic jobs. This value rises if you take possible reservations for class "A" jobs and runtimes over one minute into account. However, a reduction in the BTCTIME does not necessarily improve the system throughput. The selections may be very resource-intensive and in extreme cases, would permanently occupy a dialog work process. [6] Question: I cannot see an active job. Is my background processing system working? Answer: The problem here is to identify whether no job is started or only no active job is displayed in SM50/SM37. The job scheduler is generally triggered every 60 seconds (rdisp/btctime). If very short jobs are now selected, these cannot be displayed in transaction SM50, because the likelihood of hitting the runtime point when you refresh is very small. It is better to trace the time controlled scheduler in transaction SM61 and evaluate the entries in the trace files of a dialog work process. to evaluate. 'ARFC jobs' from the RFC area are typical examples of these short transactions. [7] Question: Why are there lengthy delays in starting background processing? Answer: First you must determine whether the background processing system is working (Question 6). If this is clarified, the analysis can be started. How you proceed depends on this analysis:

o o o o o

Are jobs actually running? Are jobs executed with immediate start or event start? Are there many short transactions in the system? Does the problem affect the overall system or only an instance? Does the background processing scheduler not select any jobs?

[8] Question: How are the spool requests assigned? Answer: The step information is stored in table TBTCP. This has space for exactly one spool request (field LISTIDENT). You can only store one spool request even if a step generates several spool requests during processing. In this case, the application is responsible for a "spool overview". [9] Question: What is not a background processing problem? Answer: Despite the similar name, the background input (BC-ABA-SC) has nothing to do with the background processing system. Even if a background (batch) input session is imported in the background, this is not a batch processing system problem. All problem that occur after a job step is started are not caused by the background processing system, but by an error in the report executed or the runtime environment. This is especially the case if a report behaves differently in the background than it would online. Notes 545241 and 573128 provide assistance during troubleshooting.