Prioritization Strategies for Class A Jobs  

Optionally, you can keep background processing work processes free for high priority jobs, jobs of class A. You specify a number of background work processes to keep open. The CCMS keeps that number of processes open for class A jobs, up to the number of background work processes in the application server.

Reserving work process(es) for class A does not reserve any particular work process in a server for class A jobs. Rather, it tells the CCMS to keep that number of work processes free at all times for class A jobs.

Procedure

Set the number of work processes to keep free in the definition of an instance (R/3 application server) as follows:

  1. Choose Administration ® CCMS. Then choose Configuration ® Op modes/Servers.
  2. Set the number of background workprocesses of class A. You’ll find instructions for doing this in Setting the Work Process Distribution. Make the setting for each operation mode in which the class A reservation should be in effect.

    3. Recommended values:

    0 The default value. Use this value if you do not have mission- or system-critical class A jobs that must always start immediately when they become eligible to start.

    In this case, jobs are run according to their class priorities. Work processes are not held open for class A jobs.

    1 Use this value to be sure that mission- or system-critical jobs start immediately when they become eligible to start.

    One background processing work process will always be kept free for jobs of class A. This value ensures that no job of class A has to wait for a free background work process. See also Deciding How to Use Class A Reservations, below.

    Be sure that the number of class A work processes is less than the total number of background work processes in an application server. Otherwise, only jobs of class A are eligible to run at that server.

    Should you wish to reserve an application server exclusively for class A jobs, then set the class A value to the number of background work processes. If an R/3 server offers 4 background work processes and the class A reservation for the server is set to 4, then only class A jobs can start at that server.

  3. The class A setting is in effect whenever the operation mode(s) in which it is defined are active.

Deciding How to Use Class A Reservations

The three job priority classes (A, B, and C, in order of priority) and the class A reservation let you choose between two strategies for prioritizing your background jobs. These are as follows:

In this case, you’ll probably want to use classes B and C to provide a secondary two-level job prioritization. In this system, class B jobs get free background work processes before class C jobs. This system operates separately from the class A critical track, since class B and C jobs can never block a class A job.

This system does not guarantee an open path for class A jobs. A class A job might have to wait if all work processes are busy, even if they are running class B and C jobs. However, class A jobs that are waiting are guaranteed to start before class B and C jobs that are also waiting. Unlike the "critical track" scheme, no work processes are kept idle for class A jobs.

If the class A workload is not high and/or there is rarely a bottleneck in background processing (at least one work process is usually free), then there may be no advantage in reserving a work process for class A jobs. The reservation may simply result in a work process rarely being used.

Work process reserved for class A: A server is set up with three work processes for background processing. The - Class A field is set to 1, keeping one work process always open for class A jobs.

The situation looks initially like this:

Background work process 1: Reserved for class A job
Background work process 2: Free for any job
Background work process 3: Free for any job

Assume that a class A job arrives. It runs in one of the three free background wokr processes. The CCMS keeps one of the remaining free background processes free in the event that another class A job arrives. One work process remains for jobs of classes B and C.

The situation is therefore as follows:

Background work process 1: Running class A job
Background work process 2: Reserved for class A job
Background work process 3: Free for any job

Assume a second case: All three background processes are free and the following jobs become eligible to start: 2 jobs of class A, 1 job of class B, and one job of class C.

The two class A jobs start immediately. The CCMS reserves the last remaining background work process for the eventual arrival of another job of class A. The class B and class C jobs must both wait; they cannot currently be started.

When one of the class A jobs finishes, the class B job can start. Again, the CCMS reserves the other free work process for new class A jobs. The class C job must continue to wait.

Here’s how this case looks initially:

Background work process 1: Running class A job
Background work process 2: Running class A job
Background work process 3: Reserved for class A job
Waiting for free work process: Class B job
Class C job

When one of the class A jobs finishes, the situation looks like this:

Background work process 1: Running class A job
Background work process 2: Running class B job
Background work process 3: Reserved for class A job
Waiting for free work process: Class C job

Finally, the situation might look like this:

Background work process 1: Running class C job
Background work process 2: Reserved for class A job
Background work process 3: Free for any job
Waiting for free work process: No jobs

No work process reserved for class A jobs: An server is set up with three work processes for background processing. There’s no "keep free" reservation for class A jobs.

Assume that all three work processes are busy running background jobs. During this time, a job from each class becomes eligible to run. The class A job, though eligible to start, cannot do so because no work process is free. When one becomes free, it is the first job to run.

Here’s how this case looks initially:

Background work process 1: Running class x job
Background work process 2: Running class x job
Background work process 3: Running class x job
Waiting for free work process: Class A job
Class B job
Class C job

When one of the jobs that’s running finishes, the situation looks like this:

Background work process 1: Running class x job
Background work process 2: Running class A job
Background work process 3: Running class x job
Waiting for free work process: Class B job
Class C job

Let’s assume that another class A job becomes eligible to start. It too must wait, because all of the background work processes are busy. But it goes to the head of the queue. When a work process becomes free, it starts ahead of the class B and C jobs, even though these have been waiting longer.