Computing Center

Management System

SAP Background Processing:Concepts and Features

September 992

Copyright

© Copyright 1998 SAP AG. All rights reserved.

No part of this brochure may be reproduced or transmitted in any form or for any purposewithout the express permission of SAP AG. The information contained herein may be changedwithout prior notice.

SAP AG further does not warrant the accuracy or completeness of the information, text, graphics,links, or other items contained within these materials. SAP AG shall not be liable for any special,indirect, incidental, or consequential damages, including without limitation, lost revenues or lostprofits, which may result from the use of these materials. The information in this documentation issubject to change without notice and does not represent a commitment on the part of SAP AG forthe future.

Some software products marketed by SAP AG and its distributors contain proprietary softwarecomponents of other software vendors.

Microsoft®, WINDOWS®, NT®, EXCEL® and SQL-Server® are registered trademarks ofMicrosoft Corporation.

IBM®, DB2®, OS/2®, DB2/6000®, Parallel Sysplex®, MVS/ESA®, RS/6000®, AIX®, S/390®,AS/400®, OS/390®, and OS/400® are registered trademarks of IBM Corporation.

OSF/Motif® is a registered trademark of Open Software Foundation.

ORACLE® is a registered trademark of ORACLE Corporation, California, USA.

INFORMIX®-OnLine for SAP is a registered trademark of Informix Software Incorporated.

UNIX® and X/Open® are registered trademarks of SCO Santa Cruz Operation.

ADABAS® is a registered trademark of Software AG.

SAP®, R/2®, R/3®, RIVA®, ABAP/4®, SAP ArchiveLink®, SAPaccess®, SAPmail®,SAPoffice®, SAP-EDI®, R/3 Retail®, SAP EarlyWatch®, SAP Business Workflow®, ALE/WEB ,Team SAP , BAPI , Management Cockpit are registered or unregistered trademarks of SAPAG.

September 99 3

Table of Contents

Copyright ........................................................................................................................................... 1

SAP Background Processing: Concepts and Features..................................................................... 4

Background Processing in Overview ............................................................................................... 5

The Job / Job Step Concept..............................................................................................................10

The Event Concept and Event Processing ......................................................................................13

Parallel Processing of Jobs with Asynchronous RFC .....................................................................16

External Commands and External Programs .................................................................................18

September 994

SAP Background Processing: Concepts and FeaturesR/3 Background processing is a method for automating routine tasks and for optimizing use ofyour organization’s R/3 computing resources. In background processing, you order the R/3System to run programs for you. You or your users tell the system what program to run andwhen to run it by scheduling “background jobs.”

Background processing lets you and your users move long-running or resource-intensiveprogram runs to periods of low system load. It also lets you and your users delegate the runningof reports or programs to the system. Your dialog sessions are not tied up, and reports that run inthe background are not subject to the limit on the run time for a dialog step that applies tointeractive sessions.

The R/3 System offers sophisticated support for background processing. You can choose from avariety of methods for scheduling and maintaining jobs. You can run both R/3-internal andexternal programs. And, for easier scheduling and management, you can run related internaland/or external programs as “job steps” within a single background processing job. Job steps leta background job represent a complex task that consists of multiple processing steps. Schedulingthe job includes all processing activities needed to perform the task.

There are also sophisticated tools, including a graphic monitor, for managing jobs anddiagnosing problems, should any occur. There is also a powerful and easy-to-use programminginterface for developing your own background-processing applications. In addition, there is alsoa job scheduling wizard that automates basic background job definition and can walk novice R/3users through the entire process.

Finally, the background processing system has an interface to external management tools. Youcan integrate your R/3 background processing into an external tool, if required. Certifiedimplementations of this interface are available in several external system management tools.

This section reviews the implementation of and important concepts in R/3 backgroundprocessing. After you have read this section, you should have a good understanding of how thebackground processing system is put together. This knowledge should help you use thebackground processing system more effectively and prevent or swiftly diagnose any problemsthat may occur.

September 99 5

Background Processing in OverviewHere is a brief overview of how background processing works in the R/3 System. This diagramshows the components that are involved in processing various types of R/3 background jobs.

External ProgramManagement

ABAP ParallelRFC

Operating SystemLevel

Other R/3 Servers

Spool outputManagement

DialogWork Processes

Job Scheduling Job Management

SM36 SM37Program Program

Job StorageManagement

- Start Job

- Process jobsteps

- Process inparallel (if appl.)

- Start successor jobs(if appl.)

Jobstart management

Background work process

Dialog work process

ABAP/4 programmanagement

Application Server + Database

Spool outputManagement

JobLog1Program1

Programn

Job1

Jobm

1. Job scheduling: Before the background processing system can do anything, background jobshave to be scheduled. This can occur in transaction SM36 (job scheduling), in the ABAPeditor (Transactions SA38 and SE38, the “start program in the background” executionoption), or through the programming interface or external interface of the background

September 996

processing system. Many R/3 applications use the internal programming interface toschedule long-running reports for background processing.

2. Job storage management: Jobs are stored in the R/3 database. Principal tables in thebackground processing system include the following:

− TBTCO: The job header table (job management data)

− TBTCP: The job step table (individual processing steps in jobs)

− TBTCS: The control table for the time-driven job scheduler

− BTCEVTJOB: Jobs scheduled to wait for an event

Job logs are held in the R/3 “TemSe” (Temporary-Sequential Objects) database. TheTemSe is set always to hold job logs as files in your host systems.Accessing job logs for display and managing job log storage is transparent for you. Youcan display or delete job logs by way of the job overview (transaction SM37) or thegraphical background monitor. Old job logs are removed automatically together with thejobs to which they belong by the ABAP program RSBTCDEL, which should always bescheduled to run periodically.

3. Job start management:

Schedulers: There are two job schedulers in the R/3 system:

− The time-driven job scheduler runs periodically to check for jobs that were scheduledto run according to some kind of time criterion (start date or calendar date, forexample). By default, the scheduler runs every 60 seconds in each R/3 server that hasat least one work process for background processing. The start interval is controlledby the system profile parameter rdisp/btctime.

1. The time-driven job scheduler takes over the starting of event-based jobs if thesejobs cannot be started when the corresponding event is triggered (for example, nofree background work processes are available). Such jobs are managed as jobs whosestart time and date has already arrived and start running as soon as possible.2. Immediate-start jobs are normally started directly by the R/3 dispatcher (withoutthe involvement of the time-driven scheduler). But these jobs are also taken over bythe scheduler if they cannot be started when they are scheduled. Like event-triggeredjobs, they are managed by the scheduler as jobs whose start time and date hasalready arrived and which therefore are immediately eligible to run.

− The event-driven scheduler is started whenever an event is triggered in thebackground processing system. Events are objects in the background processingsystem. They do not have anything to do with workflow events, nor do they haveany system-wide meaning. A typical event is, for example, the system event “Jobcompleted.”3. The scheduler checks for and starts any jobs that were scheduled to wait for theevent and (optionally) for the event argument. Jobs that were scheduled with thestart-time options After event, At operation mode or After job are event-driven.

4. There are two possible origins for events: those created within R/3 and thosegenerated at the operating system level, or external events. Events are automaticallypassed by the message server to an active background processing server. The R/3System must be active to respond to external events. An event triggered by anexternal program when the R/3 System is not running is lost.

September 99 7

Both schedulers run in dialog work processes. If they find an eligible job, then theytrigger the execution of the job in a background work process.Start eligibility: A job becomes eligible when both of the following are true:

a) The start specification of the job is fulfilled. Start specifications can be time based(including immediate start), calendar based, or event driven.

b) The job has been released to run.

5. No job, even those scheduled for immediate execution, can run until it has beenreleased. The release requirement offers an optional mechanism for controlling whatis submitted for background processing. If desired, the system can be set up so thatan administrator can check jobs before releasing them to run.6. The release requirement can be turned off on a per-user basis. Trusted users canbe given a special authorization (authorization object S_BTCH_JOB (Batch Processing:Operations on Batch Jobs) value RELE). When such a user schedules a job, the job isalso automatically released.

4. Job processing: Jobs run in a special type of R/3 work process, the background workprocess. Background work processes are different from dialog work processes in that:

− The time limit for execution of a dialog step is not in effect for background workprocesses. This time limit prevents users from executing very long-running reportsinteractively. If a dialog step in a transaction exceeds (by default) 300 seconds, it isterminated by the system. This limit is controlled by the system profile parameterrdisp/max_wprun_time .

− Background work processes allocate memory differently than dialog work processes.The purpose is to let background work processes grow as large in allocated memoryas they need to be to process the large volumes of data associated with backgroundprocessing.

The segregation of background processing to special work processes gives you anadditional dimension for separating background processing and interactive work on thesystem. It’s customary of course to separate background processing and interactive workon the system temporally (for example, interactive users have the system during the day,large background jobs have the system by night). But R/3’s background work processalso lets you separate interactive from background use by server, since background jobscan only run on those servers that offer background work processes.The use of background work processes also lets you use operation modes to change theconfiguration of your R/3 System to optimize background or dialog processing. In a“night” mode, more servers can offer more background work processes to take care ofbackground processing jobs that are scheduled to run when interactive users are notpresent. In “day” operation, you could restrict background processing to fewer serversand/or fewer background work processes.

Jobs can specify a particular background server (an R/3 application server that has atleast one background work process) for their execution. However, it’s best to leave thechoice of background server to the background system. The system then uses a load-

September 998

balancing mechanism to distribute the background processing workload among theavailable servers.When a time-driven scheduler is activated, it starts the jobs for which it has free workprocesses. If there is another background processing server, then the scheduler in thatserver starts the remaining jobs for which it has capacity, and so on.

Parallel processing (asynchronous RFC) is the only exception to the rule that jobprocessing only occurs in background jobs. A report that has been programmed forparallel processing runs in a background work process. But it can dispatch work toavailable dialog processes.You can monitor background work processes with the graphical job scheduling monitorand with the server and work process overviews (transactions SM50 and SM51).Processing of ABAP Programs: To run an ABAP program in the background, you mustprovide it with a variant (for reports with selection screens) or it must supply its ownruntime parameters. You can specify the R/3 user under whose authorizations theprogram should run, and you can also specify how lists or other output from theprogram should be handled by the R/3 spool system.If an ABAP program generates output, then this output is held in the R/3 spool systemas a spool request. The job step printing and archiving specifications (Print specificationsfunction) allow users to specify how such output is to be handled. It is also possible tohave spool requests automatically mailed by way of the SAPoffice to a user designated inthe job definition. Because output can be rather large, this option should be used withcare.Processing of external commands and external programs: To run an external, non-R/3program, you must identify the host on which the program is to run and also specify thepath name of the program and any arguments that the program requires. Thebackground processing system starts the external program by starting an SAP serverprogram (SAPXPG) on the target host system. R/3 uses R/3 RFC (Remote FunctionCalls) to communicate with SAPXPG.

The background processing system lets you specify how the execution of the externalprogram should be managed. For example, in synchronous execution, the backgroundjob waits until SAPXPG returns with the final status of the external program. Inasynchronous execution, the job proceeds immediately to the next job step once it hasstarted SAPXPG. In synchronous execution, you can retrieve error output and a returncode from the external program.The background processing system makes a distinction between external commands fornormal users and external programs for system administrators. You can see thisdistinction in the job scheduling transaction (Transaction SM36), where separate fieldsfor external commands and external programs are offered.Briefly, external commands are pre-defined commands for end users. They are operating-system independent, because there is a different variant of each command for eachoperating system that R/3 supports. They are protected by authorizations, so that normalend users can schedule only the commands that the system administator permits them to.External programs are unrestricted commands that a user with administratorauthorization can enter in a job step. There is no restriction on the command that theadministrator can type in; the command is neither pre-defined nor is it protected by R/3authority checks.

September 99 9

The purpose of this distinction is to let system administrators execute any requiredexternal program while restricting normal users to authorizations-tested externalcommands.

5. Managing background processing: The background processing system lets you trackbackground processing activity in your R/3 System with list-oriented and graphicalmonitors.

The monitors:

− The list-oriented monitor (transaction SM37) offers an administrator full control overbackground processing. From the main status display, you, as an administrator, candisplay job details, change or withdraw scheduling and release, display job logs, anduse debugging and error analysis tools. If you have the required authorization, youcan also display the spool requests generated by ABAP job steps.

− The graphical monitor (transaction RZ01) is specialized for system operators. It offersa Gantt-chart view of background processing, showing all completed, active, andreleased jobs on a time-line across all available background servers and workprocesses. The system tracks previous job performance, so that repeated jobs arealways shown with Gantt chart lengths that reflect previous run times.

Problem analysis support includes the background job logs, which record all messagesissued by programs run in the background.

The only exception: batch-input messages are recorded in the batch input log (transactionSM35) rather than in the background processing log. Further, whether output fromexternal programs is logged depends on whether the external command or program isstarted synchronously or asynchronously and how the job step control flags for programoutput are set. In asynchronous mode, the background processing system does not waitfor completion of an external command or program before starting the next job step orcompleting the job. In this case, output from the external command or program is notcaptured in the job log.Background job logs also contain job progress and status messages from the backgroundprocessing system itself.You can also use a variety of tools for analyzing and checking the background processingenvironment, and you can use standard ABAP debugging to “capture” a job while it isrunning. The best places to start looking for information are the job log and the R/3system log.

September 9910

The Job / Job Step ConceptThe work unit of the R/3 background processing system is the background job. Each backgroundjob can consist of one or more job steps.

Background Job

Program 1

Job Step 1: ABAP Program Name: RSWGZS2 Variant: SBTC

Job Step 2: External Command Name: Generic_Backup Parameter: String Operating System: Windows NT Target computer: Host1

Job Step 3: External Program Name: Path and Command Parameter: String Target computer: Host1

Job Step n: ABAP Program Name: ... Variant: ...

The job / job step concept makes it possible for you to treat jobs as logical tasks. That is, you canschedule several programs that are needed for completing a particular task as steps within asingle job. The advantage: the job acts as a logical container for the steps needed to complete thetask. You need to schedule or review only the background job in order to schedule or revieweach of the steps necessary for completing the task.

Assume that a particular data transfer with batch input requires that you start twoprograms, one external to prepare the batch-input session, the other an internalprogram to process the session. The job concept lets you handle the two programs asa single unit; each program is scheduled as a step within a single job. Scheduling thejob schedules both programs. Reviewing the job log shows you the results of eachprogram’s run.

Some background processing attributes apply to jobs and therefore to all job steps within a job.For example, the start time of the job is the earliest possible start time for any of the job steps.Also, repeat specifications, priority and other global attributes apply to the whole job.

September 99 11

BACKGROUND JOB: WORK UNIT FOR BACKGROUND PROCESSINGJOB NAME: 1997 / 12/13 ...

A These job attributes apply to theentire background job

WEEKLYJOB CLASS:JOB FREQUENCY:

JOB STEP I: JOB STEP 2:RUN A PROGRAM ASPART OF A JOB

RUN A PROGRAM ASPART OF A JOB

PRODUCEBI SESSION:EXEPRODUCEBI

AUTHUSER1AUTHUSER2

EXTERNALPROGRAM:

ABAP PROGRAM:

USER:USER:

These jobstepsattributescan be setfor eachstep.

CONTROL FLAGS:PRINTPARAMETERS: PRINTING P330

WAIT FOR EXTERNALPROGRAM TO END

. . .

To ensure that you can flexibly carry out individual programs, you can set important attributesindividually for each job step. Each step can have its own spool (output) specifications, rununder the authorizations of a separate user, use a different R/3 language (German, English, andso on) and, for programs external to the R/3 System, have its own runtime options (such ashandling of error output, synchronicity, and so on).

In general, job steps run sequentially and synchronously in the order that you enter them in a job.The first step starts, runs, and is completed. Then the second step starts, and so on. The onlyexception occurs 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 fromthe external program. If the external program runs a long time, then the start of the next job stepmay overlap with it.

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

There are two types of job steps:

• Execution of an ABAP program

You can only execute ABAP programs of type 1 (executable program). You cannot use amodule pool or a function group, which are a collection of ABAP modules.The specifications required for an ABAP job step are as follows:ABAP program + Variant + Print and archiving parameters + Language

• Execution of an external command or external program

This type of job step allows you to run programs outside the R/3 System. With Release4.0, the system distinguishes between external commands and external programs.External commands are pre-defined, authorization-protected commands for end users.External programs are directly-entered unrestricted commands that are reserved forsystem administrators.

September 9912

For both external commands and external programs, the type of non-R/3 program isunrestricted, which means that you can use compiled programs and scripts. Suchprograms can be run on any computer that can be reached from the R/3 System.Parameter passing to non-R/3 programs is not restricted in any way (except by the pre-definition mechanism for external commands).

Output of non-R/3 programs, particularly error messages, are included in the log file ofthe relevant job.The specifications required for an external command or program are as follows:

− External command + Type of operating system + Parameters (if allowed) + Targethost system

− External program + Parameters + Target host system

September 99 13

The Event Concept and Event ProcessingIn addition to time- and calendar-based scheduling, the R/3 background processing systemsupports event-driven job scheduling. Here is some background information for understandingbackground processing events and their uses and processing.

ABAPProgram

Event Scheduler

JobManagement

...

...

DIALOGWP

DIALOGWP

BACKROUNDWP

BP_EVENT_RAISE...

R/3 System

Server 1

NON-R/3 Program

Server 2

JobEvent: Job_ChainJOB1_is_Done

Event Job_Chain

Event

Call to

Event: JOB2_is_Done

SAPEVTJOB2_is_Done

SAPEVT

Parameter: JOB1_is_Done

Parameter: <None>

Event Validity: Only in the Background Processing SystemEvents have meaning only in the background processing system. You can use events only to startbackground jobs.

September 9914

Triggering an event notifies the background processing system that a named condition has beenreached. The background processing system reacts by starting any jobs that were waiting for theevent.

Events are not saved. They are used to activate any jobs already waiting for them. They are thendiscarded.

Types of EventsThere are two types of events:

• System events are defined by SAP and are triggered automatically by system changes like theactivation of a new operation mode. You can not modifiy system events.

• User events are events that you define yourself. You must trigger these events yourself fromABAP or from external programs. You could, for example, signal the arrival of external datato be read into the R/3 System by using an external program to trigger a backgroundprocessing event.

Event ArgumentsYou can qualify an event with an event argument. An event argument is a text string that youcan optionally associate with an event. You can specify an event argument during the followingoperations:

• when you schedule a job to wait for the event

• when you trigger an event.Unlike event IDs, event arguments are not defined in the R/3 System.

If you specify an argument when you schedule a job, then the job is eligible to start only when theevent is triggered with the argument.

If you do not specify an argument when you schedule a job, then the job can start as soon as theevent occurs. The job is eligible to start no matter what argument string is supplied with theevent.

When a Job Waiting for an Event May Start

Job Event Result

Job scheduled with EventID “JSTART” Argument“A”

JSTART triggered, noargument

Job does not start,continues to wait forJSTART A

JSTART triggered withargument “A”

Job starts

JSTART triggered withargument “B”

Job does not start;continues to wait forJSTART.

Job scheduled with EventID “JSTART”, no argument

JSTART triggered, noargument

Job starts

September 99 15

JSTART triggered with anyargument

Job starts

An ABAP program that is running as a background job can find out what event and argumentwere presented when it was started. This makes it possible for ABAP programs running in thebackground to react intelligently to an event depending upon the argument string that wassupplied with it.

Example: Events and Event ArgumentsSwitching to a different operation mode triggers an event in the background processing system.The event is an R/3 System event named SAP_OPMODE_SWITCH. As an argument, the eventcarries the name of the new operating mode.

If you schedule a job to wait upon the event SAP_OPMODE_SWITCH with argument NIGHT,then your job will become eligible to start when the operating mode NIGHT next becomes active.

You can also schedule jobs to be repeated whenever an event occurs. In the previous example,your job would be run whenever operating mode NIGHT becomes active, not just the first timethat the event occurs.

You can schedule a job to wait for an operation mode to become active with theOperation mode button in the job scheduling function. You need not schedule the jobto wait for the SAP_OPMODE_SWITCH event.

September 9916

Parallel Processing of Jobs with Asynchronous RFCFor some R/3 reports, the nights are getting too short. Especially at customers with largevolumes of data, some R/3 reports that customarily run in the background processing system(such as material planning runs) have run times of many hours. It can be difficult to finish suchjobs runs in the “night-time” that is available, especially if dialog users are spread across severaltime zones.

With Release 3.1, SAP offers a solution to the “short nights” problem: parallel-processedbackground jobs. Long-running R/3 reports can now implement parallel processing, which letsthemABAP parcel out the work to be done to available work processes in the R/3 System andthen collect and synchronize the results.

In parallel processing, a job step is started as usual in a background processing work process. Ifthe program that runs in the job step is so programmed, it can use a special variant ofasynchronous RFC to have portions of the data that is to be processed run in parallel in otherwork processes. You can recognize such a program because it uses the CALL FUNCTIONSTARTING NEW TASK DESTINATION IN GROUP instruction to start the function modulesthat process the data.

While the job itself runs in a background process, the parallel processing tasks that it starts run indialog work processes. Such dialog work processes may be located in any of the servers of yourR/3 System.

Parallel processing has been implemented in some R/3 applications that have long-runningreports. Check the application documentation for information on such reports. The parallelprocessing interface is also available to customers.

Automatic Protection Against Resource OveruseThe asynchronous remote function call (RFC) system contains built-in safeguards against thepossibility that a parallel processing job may take too many resources and affect the overallperformance of your R/3 System.

September 99 17

A parallel-processed job may use the dialog work processes of an R/3 server only if the followingare true:

• The server in question has at least three free dialog work processes. This restriction meansthat at least two dialog work processes remain free for other work in any server that is usedby a parallel processing job. The job can start a task in a dialog work process only if twoother dialog work processes are currently free in the application server in question.

• The dispatching queue of the server in question is less than 10 percent full. This restrictionprevents a parallel processing job from using a server that is already quite busy.

Performance testing at SAP suggests that the built-in safeguards allow significantly fasterexecution of background jobs without unduly affecting R/3 System performance as a whole.However, if parallel-processed jobs may compete for the same resources, or if parallel-processedjobs may share the R/3 System with time-critical applications or a full complement of interactiveusers, then we recommend that you use RFC groups to control which resources a parallel-processed job uses.

Managing Resources with RFC GroupsBy default, the “group” of servers eligible for use for parallel processing is all qualifiying serversin your R/3 System. However, you can use the “group” specification in a parallel-processingprogram to control precisely which resources may be used by a parallel processing job.

A group specifies the set of R/3 application servers that can be used for executing a particular jobin parallel. The “default” group (CALL FUNCTION STARTING NEW TASK with the argumentDESTINATION IN GROUP DEFAULT), is all qualifying servers. But you can also create yourown more limited groups. You can view and maintain groups with transaction RZ12 (Tools →Administration → Administration → Network → RFC destinations and then RFC → RFC groups).

MonitoringAt this time, parallel processing jobs are not specially marked in the tools for monitoringbackground processing. However, a monitoring capability is expected to be added in comingreleases of the R/3 System.

September 9918

External Commands and External ProgramsThe background processing system makes a distinction between external commands for normalusers and external programs for system administrators. You can see this distinction in the jobscheduling transaction (SM36), where separate fields for external commands and externalprograms are offered.

ExternalProgram

ExternalCommand

Ftp_get_data

System Administrator

R/3

OS

User

Name Command

Briefly, external commands are predefined commands for end users. They are operating-systemindependent, because there is a variant of each command for each operating system that R/3supports. They are protected by authorizations, so that normal end users can schedule only thecommands that the system administator permits them to.

External programs are unrestricted commands that a user with administrator authorization canenter in a job step. There is no restriction on the command that the administrator can type in; thecommand is neither pre-defined nor is it protected by R/3 authority checks

The purpose of this distinction is to let system administrators execute any required externalprogram while restricting normal users to authorizations-tested external commands. In more detail:

• With an external program, a system administrator may enter any desired host operatingsystem command or program in a job step. No R/3 authorizations test is carried out beforeexecuting the command.External programs give an administrator -- a user with the background processingadministration authorization (authorization object S_BTCH_ADM Batch processing: BatchAdministrator) -- the flexibility to run any required host system command without anyadministrative preparation in the R/3 System.

• With an external command, an ordinary end user -- any user without background processingadministrator authorization -- may run a host system command or program that has beenpre-defined by the administrator in the R/3 System. The user who schedules the externalcommand must have the authorization required for the external command.

September 99 19

External commands let you control what your users do outside the R/3 System. Endusers can run only the commands and arguments that you specify in external commanddefinitions. And you can control access to external commands with R/3 authorizations.For additional security and comfort, external command definitions are operating-systemspecific. For example, you can define variants of a command for UNIX and Windows NThosts. A user who schedules an external command must specify the type of operatingsystem in which the command is to run. The system then automatically selects thecorrect operating system variant or issues an error if the required variant has not beendefined.