Creating a Background User

Use

If you want to perform IDoc inbound processing in the background, you require a background user in every child system that you can use instead of your own user name to schedule the background jobs in transaction SM37.

Procedure

...

1. In the child system, choose Tools ® Administration ® User Maintenance ® User (transaction SU01).

2. Create a background user in accordance with the naming convention for system users (such as CUA_PRD_BACK).

3. Assign the user type System to the user, and deactivate the password (see Logon Data Tab Page).

4. Assign the role Z_SAP_BC_USR_CUA_CLIENT_BATCH to the user.

5. Save your entries.

Data Transfer Methods

You can use the following methods to transfer data:

· Direct input: With direct input, the SAP function modules execute the consistency checks. However with batch input, these consistency checks are executed with the help of the screens. This means that direct input has considerable performance advantages.

· CALL TRANSACTION: Data consistency check with the help of screen logic.

· Batch input with batch input sessions: Data consistency check with the help of screen logic.

Difference between Batch Input and CALL TRANSACTION

If the direct input cannot be used for your task, this makes creating a data transfer program easier since the underlying transactions ensure that the data consistency checks are executed.

In the case of an error during the data transfer (if data records are inconsistent, for example), you can restart the transfer at the point in the program where the error occurred.

Data Transfer Overview

Batch input methods

With the batch input method, an ABAP program reads the external data that is to be entered in the SAP system and stores the data in a “batch input session”. The session records the actions that are required to transfer data into the system using normal SAP transactions.

When the program has generated the session, you can run the session to execute the SAP transactions in it. You can explicitly start and monitor a session with the batch input management function (by choosing System ® Services ® Batch input), or have the session run in the background processing system.

CALL TRANSACTION methods

In the second method, your program uses the ABAP statement CALL TRANSACTION USING to run an SAP transaction. External data does not have to be deposited in a session for later processing. Instead, the entire batch input process takes place inline in your program.

The information in Choosing Data Transfer Methods will help you decide which is the best data transfer method.

Easy Job Scheduling Using BP_JOBVARIANT_SCHEDULE

To schedule a job from within a program using the express method, you need only call the BP_JOBVARIANT_SCHEDULE function module.

The express method has the following characteristics:

• Simplified job structure: The function module schedules a job that includes only a single job step.
• The function module uses default values for most job-processing options. You cannot, for example, specify a target printer as part of the call to the function module. Instead, the job step uses the print defaults of the scheduling user.
• Only ABAP reports can be scheduled. You must use the "full-control" method to start external programs.
• The range of start-time options is restricted. Event-based scheduling is not supported.

The function module works as follows:

1. You name the report that is to be scheduled in your call to the function module.
2. The function module displays a list of variants to the user. The user must select a variant for the report.

You must ensure that the variants required by your users have already been defined.

3. The user picks either "immediate start" or enters a start date and start time. Optionally, the user can also make the job restart periodically. The job is then scheduled.

Example

You could use the following code to let users schedule report RSTWGZS2 for checking on the status of online documentation:

call function 'BP_JOBVARIANT_SCHEDULE'
exporting
title_name = 'Documentation Check' " Displayed as title of
" of scheduling screens
job_name = 'DocuCheck' " Name of background
" processing job
prog_name = 'RSTWGZS2' " Name of ABAP
" report that is to be
" run -- used also to
" select variants
exceptions
no_such_report = 01. " PROG_NAME program
" not found.
call function 'BP_JOBVARIANT_OVERVIEW' " List the jobs that
exporting " have been scheduled
title_name = 'Documentation Check' " Displayed as title
" of overview screen
job_name = 'DokuCheck' " Jobs with this name
" are listed
prog_name = 'RSTWGZS2'
exceptions
no_such_job = 01.

The code would present your users with a sequence of two screens. On the first screen, shown below, the user can select from available variants or add new variants:

On the second screen, the user can pick a start date and time for the job and decide whether the job should be repeated periodically. The function module finishes with a success message when the user schedules the background job.

See also Managing "Easy-Method" Jobs with BP_JOBVARIANT_OVERVIEW for an easy method for letting users manage their background jobs.

Managing "Easy-Method" Jobs with BP_JOBVARIANT_OVERVIEW

With BP_JOBVARIANT_OVERVIEW, you can offer your users a simplified display and management function for their "express-method" jobs.

The function module does the following:

• displays the job title, report name and variant, start time specification, status, and scheduling user of each selected "express" job
• allows users to change the start specification and restart period of jobs that have not yet been run
• allows a user to display the job log and spool output of completed jobs
• allows users to delete jobs that are not currently executing.

Example

You could use the following code to let users check on jobs that they have scheduled with the sample code shown in Easy Job Scheduling Using BP_JOBVARIANT_SCHEDULE:

call function 'BP_JOBVARIANT_SCHEDULE' " Schedule jobs;
" counterpart to
exporting " BP_JOBVARIANT_OVERVIEW
title_name = 'Documentation Check' " Displayed as title of
" of scheduling screens
job_name = 'DocuCheck' " Name of background
" processing job
prog_name = 'RSTWGZS2' " Name of ABAP
" report that is to be
" run -- used also to
" select variants
exceptions
no_such_report = 01. " PROG_NAME program
" not found.

call function 'BP_JOBVARIANT_OVERVIEW'
exporting
title_name = 'Documentation Check' " Displayed as title
" of overview screen
job_name = 'DokuCheck' " Jobs with this name
" are listed
prog_name = 'RSTWGZS2'
exceptions
no_such_job = 01.

The user is presented with the following screen:

From this screen, your users can do the following, subject to background processing authorizations:

• delete or change the start time of jobs that have not yet started
• display the job logs and spool output generated by jobs that have been completed.

Selecting and Deleting a Job

To delete a background job explicitly, use:

• BP_JOB_SELECT to obtain the jobname and job number of the job that you wish to delete.

You can select jobs according to all of the criteria available in the interactive background processing management system:

• Jobname: Using a well-planned naming convention for your jobs will help you to select them precisely.
• Job number
• Name of the user who scheduled a job
• Specifications for the start-time window/no start time scheduled
• Start dependent upon predecessor jobs
• Start dependent upon an event and event argument
• Job status (preliminary, scheduled, ready, running, finished, aborted).

• BP_JOB_DELETE to delete the job. The job log is deleted as well, if the job has already been run.

A job cannot delete itself. Also, a job that is currently running cannot be deleted. However, you can have it deleted automatically if it is completed successfully. See the DELANFREP parameter of JOB_OPEN.

Sample Program: Deleting a Background Job

* Data declarations: BP_JOB_SELECT
*
DATA JSELECT LIKE BTCSELECT.

DATA SEL_JOBLIST LIKE TBTCJOB OCCURS 100 WITH HEADER LINE.

* Sample selection criteria
*
JSELECT-JOBNAME = 'Name of job'.
JSELECT-USERNAME = SY-UNAME.

CALL FUNCTION 'BP_JOB_SELECT'
EXPORTING
JOBSELECT_DIALOG = BTC_NO
JOBSEL_PARAM_IN = JSELECT
IMPORTING
JOBSEL_PARAM_OUT = JSELECT
TABLES
JOBSELECT_JOBLIST = SEL_JOBLIST
EXCEPTIONS NO_JOBS_FOUND = 1
SELECTION_CANCELED = 2
OTHERS = 99.
*
* In this example, the program loops over the internal table
* SEL_JOBLIST and deletes each of the jobs that was selected.
*
* Alternative: Have the user select the job to be deleted
* with BP_JOBLIST_PROCESSOR. For an example, please see
* Sample Program: Wait for Predecessor Job with JOB_CLOSE.
*
LOOP AT SEL_JOBLIST.
CALL FUNCTION 'BP_JOB_DELETE'
EXPORTING
FORCEDMODE = 'X'
JOBNAME = SEL_JOBLIST-JOBNAME
JOBCOUNT = SEL_JOBLIST-JOBCOUNT
EXCEPTIONS
OTHERS = 99.
ENDLOOP. *
*
* FORCEDMODE deletes the job header even if other portions of the
* job cannot be deleted from the TemSe facility, where they are
* held.

* FORCEDMODE can be used without fear of causing problems in the
* System. Any TemSe problem that affects background jobs can be
* resolved directly in the TemSe system and does not require the
* job header.

Analyzing Parts of the Runtime Environment

Use

The background processing runtime system consists of the following components (control objects):

· Time-based job scheduler:

Responsible for starting jobs which have a start date and time specified.

If there are jobs with a scheduled start time of After event, At operation mode or After job that cannot be started at their scheduled start time (for example, if there are no free background work processes), then these jobs will be started at the next possible opportunity. The time-based scheduler is also used to start these jobs.

The scheduler is started periodically by the dispatcher in a dialog work process, as long as there is at least one background work process on the application server and the periodic value is greater than zero. The number of background work processes is specified in the profile parameter rdisp/wp_no_btc. The periodic value is set in the profile parameter rdisp/btctime.

(The default value is 60 seconds)

· Event-based job scheduler:

If an event is raised in the SAP system, a check is made using the event-based scheduler to see if there are any jobs waiting for this event. If there are, then the event based scheduler makes sure that these jobs are started. The scheduler always runs in a dialog work process on the application server which the profile parameter rdisp/btcname points at.

· Job starter:

A job that is due to be executed will be started by the job starter. This performs all preparatory work such as reading the job data from the database and starting the job steps. The job starter runs in a background work process.

· Switching between operating modes:

The time-controlled job scheduler uses a table of times during each run to check whether a switch of operating mode is necessary. If it is, then the scheduler initiates the switch in a dialog process on the application server on which the scheduler is running.

· Zombie cleanup:

When an SAP system is started, then a check is made for “zombies”. These are jobs which have the status ready or active. Since it is of course impossible for jobs with one of these status values to exist when the SAP system is started, they are set to have status scheduled or terminated. “Zombies” are created when, for example, an application server on which a job is running is powered down before the job has finished properly. The background processing runtime system can no longer correct the status contained in the database.

· Starting external programs:

This component allows external programs to be started as part of a job step. An external program is started from the background work process in which the job is running.

Each of these components (control objects) can be analyzed separately.

Procedure

...

1. To analyze parts of the runtime environment from the CCMS initial screen, choose Jobs ® Background objects

2. Choose Maintain Objects. The system displays a list with one entry for each host and control object.

3. Choose Control object ® Change. The system displays a dialog box in which you can activate – for the next run or permanently – a control object for tracing.

4. Choose Action log to find out if the control object ran after the trace was switched on.

5. As long as the control object has run at least once, you can have a look at the trace file on the appropriate application server. To do this, choose Tools ® Administration, Monitor ® System monitoring ® Servers, Goto ® Traces (Transaction SM51)

6. In the case of control objects that run in dialog work processes, it is not possible to predict in which of the available work processes the object will be processed. However, it is quite likely to be work process 0 or 1. The best approach is to sort the list of trace files according to date and time. The trace entries should be found in one of the most recently written trace files. Look through the files for entries that have an ‘L’ in the first column.

For control objects that run in a background work process, you can find the work process number in the job detail data.

7. If you cannot evaluate the trace information yourself, send the contents of the trace file to SAP for further analysis.

Job Log Cannot Be Displayed

Procedure

Analysis	Procedure
1) Can job logs be created?	– Perform the following test on all job servers: – Schedule the job with the target server = name of host on which the job server is running. For example, you can specify the ABAP program RSPARAM as a step. Start date of job = ‘Immediate’ – Log on to job server (see Analyzing the Work Processes and System Log of an Application Server) – Can the job log be displayed (see Analyzing Job Status)? Yes: End of analysis No : Continue with step 2
2) Are there unusual entries in the system log?	– Check the system log of the job server (see Analyzing the Work Processes and System Log of an Application Server) – Are there any ‘permission denied’ entries, which indicate that the job server is not permitted to create a job log? Yes: Change the access permissions belonging to the directory in which the job log was created, so that the user ID in which the job server is running (generally c11adm) is given read and write permission for the directory – End of analysis No : Test on the job server whether the TemSe subsystem used for creating job logs is working (see Analyzing Status, Configuration, and Administration Data) – Does the test report errors? Yes: You will now find entries in the system log which describe the problem in more detail End of analysis No : Continue with step 3
3) Is the job log supposed to be displayed on an application server other than the job server?	– Find out which host the job is to be executed on (see Analyzing Job Status) – Is the system attempting to display the job log from an application server which is running on a different host than the host on which the job is being executed? Yes: Do the application server and the job server each have their own global directory? Yes: - The job log cannot be displayed because the application server cannot access the global directory of the job server. Make the necessary changes so that both servers have the same global directory. End of analysis No: Report the problem to SAP

Deleting Jobs

Use

You delete a job for one of two reasons: the job doesn't need to be processed or the job has already run and does not need to be analyzed or documented further. Until you delete it, a job remains in the job overview. When a job is deleted, it is removed from both the overview and the associated job log.

Procedure

...

1. Select a job (or jobs) from the Select Background Jobs screen (Transaction SM37, or choose CCMS ® Jobs ® Maintenance, complete the description of the jobs you want to delete, then choose Execute to get to the Job Overview.)

2. In the Job Overview, mark the job or jobs you want to delete by checking the box to the left of the job name.

3. Choose Job ® Delete.

Deleting Jobs That Have Dependent Jobs

If you delete a job that must be processed before another job can be started, the dependent job can no longer be started. The system will inform you of any such existing dependent, or successor, jobs. You’ll then need to either reschedule or delete the dependent job.

If you try to release a job whose predecessor job was deleted, the system sets the status of the job to Planned. To start this job, you must release it and specify the start conditions.

Reorganizing Background Jobs

To delete background jobs in bulk, schedule the SAP program RSBTCDEL.

...

1. Schedule a background job that has RSBTCDEL as an ABAP program step.

2. Indicate the “variant”, or criteria, of the jobs you want to delete, including:

· job name

· name of “user”, or person who scheduled job

· job’s start and end times or dates

· “age“ of the job (e.g., older than xx days)

· job’s status (scheduled, released, finished, canceled)

· event ID or parameter for event-driven jobs

3. Run this new background job.

The program RSBTCDEL should be scheduled to run regularly to flush various database tables (TBTCO, TBTCS, BTCEVTJOB, TBTCP, etc.) to keep them from getting unnecessarily large. For more information, see Required Background Jobs.

Displaying a Job Log

Use

All message types issued by a program running in the background are stored in a job log, which you can display either to obtain information on a prematurely terminated program or to complete a detailed investigation of a particular background processing run. A separate log file is created for each job.

Deleting Log Files

You should never delete log files directly. If you want to clear the log directory, you must delete the jobs to which the logs belong. In the process, the logs are also deleted.

Job logs are held in the TemSe temporary sequential objects storage facility. TemSe is configured to always store job logs as operating system files in the shared SAP directories. If you delete log files directly at the operating system level, you create inconsistencies in the TemSe database, which you'll then need to eliminate with the Consistency check function in Transaction SP12.

Log Messages

Log messages are generally output using ABAP keyword MESSAGE. With the exception of ABAP breakpoint statistics, no other data is normally output to the job log.

ABAP Short Dumps

If an ABAP program generated a dump when it terminated abnormally, you can display the dump by clicking on the Abend message.

Batch Input Messages

Messages output during batch input sessions are not recorded in the job log. These messages are output only to the batch input system.

Procedure

...

1. Go to Select Background Jobs using Transaction SM37 or by choosing CCMS ® Jobs ® Maintenance.

2. Select the jobs you want to review in the job log by specifying conditions that identify the job or jobs, including job name, user name, job status, start condition, or contents of a job step. Execute this selection to see a list of jobs that match these criteria.

3. In the Job overview screen, select your desired job and choose Job log.

4. In the Job Log Entries for screen, the date and time of each job step is listed along with identification of any system-generated messages that apply to each step. Message types include A (Abend), E (Error), S (Successful processing completed), I (Information), and W (Warning).

5. You can print the job log (Job log ® Print list) or save the log by exporting it to a word processing, spreadsheet, or local file (Job log ® Print list ® Export ® ).

6. For further information about a particular item in the job log, select the line and choose Long text. The resulting help screen can include further information about diagnosing the message, the system’s response to the message, and how the user should follow up.

Terminated Job Analysis

Definition

If program or system errors occur, a job will terminate abnormally, and the Cancelled column in the Job Scheduling Monitor will be marked.

A job is also shown to have terminated abnormally if it was not started within the specified start time frame. This start time frame generally expires if the system is unavailable for a long time, such as during maintenance. In such cases, jobs that are no longer needed are not executed when the system is restarted.

Error messages issued by the background system and by the scheduled program are recorded in the job log. Other relevant error messages may be found in the system log, because if the background processing system cannot write a job log for any reason, all of its messages will be recorded instead in the system log.

For more information on analyzing terminated jobs, see Troubleshooting the Background Processing System.

You can check three sources for information on the cause of abnormal termination:

• The System Log

Messages on the processing status are written to the system log while a job is being processed.

To display messages issued during background processing, search for messages on the processing status. Also, find the SAP number assigned to the background work process with the Process overview function. This number stays the same as long as the number of processes in a server does not change.

To reduce the possibility of a message being issued more than once, the work process does not write a repeated message to the system log until after a specific delay period. When the problem is solved, the system writes an appropriate message for that in the system log as well.

Assume an error in the database system prevents background processing. During the first hour of the problem situation, a warning message is written in the system log several times at increasing intervals. After this first hour the message is sent hourly. Once the malfunction has been corrected, the system reports that normal operation has been resumed.

• The Job Log

All messages issued by an ABAP program with the MESSAGE statement are recorded in the job log.

• Output of an ABAP Short Dump

If an ABAP program in a job step terminated abnormally, you can access the ABAP short dump from the job log by clicking on the error message.

Job was Not Started

Procedure

Analysis	Procedure
1) Does the job have a start date?	Display the job’s start date (see Analyzing Job Status) Does the job have a start date? Yes: Continue with step 2. No: Assign the job a start date End of analysis
2) Does the user who scheduled the job have authorization to release jobs?	Display the authorizations that the user has for background processing (see Analyzing Status, Configuration and Administration Data) Does he have release authorization? Yes: Continue with step 3 No: Either give the user release authorization or have the batch administrator release the job. End of analysis
3) Has the start date been reached?	Yes: Is start date = ‘after Event’ and was the event raised using the sapevt program? Yes: Check whether sapevt is working (see Analyzing Problems With Events) – Is sapevt Notifying problems? Yes: End of analysis No: Continue with step 4 No: Either wait until the start date is reached or assign the job a new start date (see Analyzing Job Status) – End of analysis
4) Are the resources necessary for executing the job available?	– Call the graphical job monitor (see Analyzing ABAP Runtime Problems) – Does the job have a target server? Yes: Is there a free background work process on the target server for the job class requested? Yes: Continue with step 5. No: Either set up a minimum of one background work process on the target server for the job class (see Analyzing Parts of the Runtime Environment,"Switching between operating modes") or remove the target server from the job definition (see Analyzing Job Status) – End of analysis No: Is there at least one host with a free background work process for the job class requested? Yes Continue with step 5 No: Either wait until a background work process becomes free or set up an additional background work process for the job class (see Analyzing Parts of the Runtime Environment,"Switching between operating modes") – End of analysis
5) Can the time-controlled or the event-controlled job scheduler be started?	– Does the job have a target server? Yes:Check the profile parameters of the background processing on the target server (see Analyzing Status, Configuration and Administration Data) No: Check the profile parameters of the background processing on all job servers (see Analyzing Status, Configuration and Administration Data) – Are errors evident in the log? Yes:Fix the problems, e.g. change the profile parameters etc. – End of analysis No: Continue with step 6
6) Are there unusual entries in the system log?	– Does the job have a target server? Yes: Check the system log on the target server for entries (see Analyzing the Work Processes and System Log of an Application Server) No: Check the system logs of all job servers for entries (see Analyzing the Work Processes and System Log of an Application Server) – Did you find entries ? Yes: Can you solve the problem yourself? Yes: End of analysis No: Continue with step 7. No: Continue with step 7.
7) Record the background processing	– Record the component of the background processing which is responsible for starting the job (see Analyzing Parts of the Runtime Environment) – Analyze the trace information – Can you solve the problem yourself? Yes: End of analysis No: Send the trace to SAP

Job is Terminated

Procedure

Analysis	Procedure
1) Are there error messages in the job log?	– Display the job log (see Analyzing Job Status) – Are there error messages? Yes: – View the error message long texts (choose Goto ® Long text) Due to the large number of different problems which can cause termination of a job, it is not possible here to give a generalized procedure for analyzing the problems. There follows a list of some of the more commonly observed problems: – A variant of an ABAP program cannot be found, because it has been deleted – There is a syntax error in an ABAP program – There is a runtime error in an ABAP program, e.g. divide by zero – An external program cannot be started (see Analyzing Problems With External Commands and Programs) No : Could the problem be solved ? Yes: End of analysis No: Continue with step 2
2) Are there unusual entries in the system log?	– Does the job have a target server? Yes: Check the system log on the target server for entries (see Analyzing the Work Processes and System Log of an Application Server) No: Check the system logs of all job servers for entries (see Analyzing the Work Processes and System Log of an Application Server) – Did you find entries? – Can you solve the problem yourself? Yes: End of analysis No: Notify SAP of the problem

Analyzing Job Status

Procedure

From the CCMS initial screen, choose Jobs ® Maintenance.

All background processing jobs can be subjected to an analysis of job status. This analysis is concerned with the following criteria:

• Existence

• Attributes

(requested/actual start time, steps, target server, job class and so on)

• Status (scheduled, released, active, nd so on)

• Activity of a running job

You can restrict the number of jobs selected on the request screen:

It is important whether or not the user who makes the selection has an administrator authorization for background processing. If a user has administrator administration, then jobs will be selected across all clients. If not then jobs will only be selected in the client onto which the user has logged on.

The system displays a list of the jobs that were found:

This overview displays information that is of particular importance for problem analysis, that is, job status. The list is usually sorted alphabetically, but you can sort it according to other criteria (by choosing Edit ® Sort). You can sort it chronologically, for example, so that you can easily see the jobs that ran over a given time period.

The following functions are especially important for problem analysis:

• Job log:

This contains information about any problems which occurred in the job at runtime, such as whether an ABAP program was terminated or an external program could not be started.

This also contains a list of all messages which were output either by ABAP programs with the MESSAGE statement or by external programs.

• Job ® Display:

Displays all data belonging to a given job, such as the start date, steps, spool lists generated by steps, etc. The job detail information also shows on which host and in which work process the job was executed.

• Job ® Change:

To change job data such as target server, start date, steps, and so on.

• Spool List :

You can access the spool list of a job directly from here.

• Steps:

You can access the step data of a job directly from here.

• Job ® Capture:

This can be used to pause and analyze an active job which is in the middle of executing an ABAP program. An ABAP debugger window is opened, showing the ABAP program code at the point at which it is being executed. The code can now be analyzed. You exit the debugger by choosing Debugging ® Continue.

The ABAP program (the job) then continues to execute from the point at which it was stopped. You cannot use this function on external programs.

• Job ® Cancel job:

This immediately terminates an active job.

• Job ® Check status:

This allows you to check whether the status of a job as shown in the list is the same as the real status of the job. There is a database table that contains the status information of the jobs.

Situations sometimes occur (for example, a problem in the connection to the database) that prevent the background processing runtime system from entering the current status of a job in the appropriate database table. This will cause a discrepancy between the real status of a job and the status that was entered in the database.

Jobs and Job Steps Explained

Definition

The work unit of the background processing system is the background job, each of which consists of one or more job steps.

Jobs and job steps enable you to treat complex tasks as single units. That is, you can schedule several programs needed to complete a particular task as steps within a single job, with the advantage of the job being single logical container for all the steps needed to complete the task. You need to schedule or review only one background job in order to schedule or review any of the individual steps necessary for completing the task.

Assume that a particular data transfer with batch input requires that you start two programs, an external program to prepare the batch-input session and an internal program to process the session. Creating a job made up of two steps lets you handle the two programs as a single unit. Scheduling that one job schedules both programs. The results of each program's run can be seen in the job log.

Some background processing attributes apply to entire jobs and, therefore, to all job steps within a job. For example, the earliest possible start time for any job steps will be the start time for the job. Frequency of repetition, priority, and other global attributes also apply to the whole job.

To ensure that you can flexibly run individual programs, you can set important attributes individually for each job step, too. Each job step can:

• have its own spool, or output, specifications
• run under the authorizations of a separate user
• use a different language
• have its own runtime options (for programs external to the SAP System), such as handling of error output and synchronicity

In general, job steps run sequentially and synchronously in the order they're entered in a job: the first step starts, runs, and is completed, then the second step starts, and so on. The only exception is when you schedule an external program to run asynchronously. In this case, the background processing system starts the next job step without waiting for a return code from the external program. If the external program runs long enough, then the start of the next job step may overlap it.

Job steps run partially independently of each other’s status. That is, the abnormal termination of one job step does not roll back the work of a previously completed job step if this previous step was executing a commit. If any job step fails, however, then the entire job fails. No further job steps are carried out, and the job's status changes to Canceled.

There are two types of job steps:

• An executable ABAP program

Only type 1, or executable, ABAP programs can be used as job steps. Module pools and function groups, which are collections of ABAP modules, are not allowed. The specifications required for an ABAP job step are:

ABAP program + Variant + Print and archiving parameters + Language

• An external command or external program

This type of job step allows you to run programs outside the SAP System. External commands are predefined, authorization-protected commands for end users. External programs are unrestricted, directly entered commands reserved for system administrators.

The type of external command and external program is unrestricted, meaning that you can use either compiled programs or scripts. Such programs can be run on any computer that can be reached from the SAP System. Parameter passing to non-SAP programs is completely unrestricted except by the predefinition mechanism for external commands.

Output of non-SAP programs, particularly error messages, is included in the job's log file.

Specifications required for an external command or program are:

• External command + Type of operating system + (Parameters) + Target host system
• External program + Parameters + Target host system

Job Step Language

If your SAP System runs with an Arabic, Cyrillic, or Asian character set, then you may need to change the language specified in the standard background jobs listed above. Languages are assigned to jobs based on job steps. Be sure that the language specified in the job step definition in each of these jobs is set to English (EN).

This change is required because not all languages are available with all code pages. If the job’s specified language is not available, the job will not run.

Required Background Jobs

Definition

There are several background jobs that should run periodically in a production SAP System. These jobs perform housekeeping chores such as deleting outdated spool requests of background jobs.

You should schedule each of these jobs for periodic execution according to the schedule shown in the following table.

This list does not include housekeeping and reorganization programs that belong to SAP applications. See the customizing system for more information on these programs.

By following the naming conventions shown in the table, you help ensure that SAP will be able to verify that these programs are properly scheduled in the event of any problems.

Periodic Jobs Required for Housekeeping:

Job Name	ABAP Program	Required Variant	How Often?
SAP_REORG_JOBS Deletes old background jobs.	RSBTCDEL	You must create a variant.	Daily
SAP_REORG_SPOOL Deletes old spool requests.	RSPO0041	You must create a variant.	Daily
SAP_REORG_BATCHINPUT Deletes old batch input sessions. This job may not run at the same time as normal batch input activity. Schedule this job for periods during which no batch input sessions are run.	RSBDCREO	You must create a variant.	Daily
SAP_REORG_ABAPDUMPS Deletes old dumps produced by ABAP abnormal terminations. Alternative: To keep from needing to schedule this job, run the ABAP report RSNAPJOB from the ABAP editor instead. This schedules RSSNAPDL as follows: Job name: RSSNAPDL Variant name: DEFAULT (you must create this variant) Start time: 0100 AM Repeat interval: Daily	RSSNAPDL	You must create a variant.	Daily
SAP_REORG_JOBSTATISTIC Deletes job statistics for jobs not run since the specified date (statistics no longer needed since job was a one-time occurrence or is no longer run)	RSBPSTDE	You must create a variant.	Monthly
SAP_REORG_UPDATERECORDS Deletes old completed update records (automatic delete deactivated); deletes incomplete update records (automatic delete deactivated) Run this job ONLY if: · You have deactivated the default automatic deletion of update records once they have been processed. This function is controlled by the system profile parameter rdisp/vb_delete_after_execution · You have deactivated the default automatic deletion of incomplete update records (records that are partially created when an update header is created and saved but the generating transaction then ends abnormally). This function is controlled by system profile parameter rdisp/vbreorg · You have deactivated processing of V2 update components after the processing of the associated V1 updates. This function is controlled by system profile parameter rdisp/vb_v2_start.	RSM13002	None.	Daily
SAP_COLLECTOR_FOR_JOBSTATISTIC Generates runtime statistics for background jobs	RSBPCOLL	None.	Daily
SAP_COLLECTOR_FOR_PERFMONITOR Collects system performance statistics This job was previously called COLLECTOR_FOR_PERFORMANCE_MONITOR. When scheduling this job, be sure to use the new name. RSCOLL00 schedules all reports that need to run for the performance monitor using table TCOLL to determine what to run. See the CCMS Guide for more information on setting up RSCOLL00.	RSCOLL00	None.	Hourly