If a failing node has a batch job running on it, the batch job is aborted. You need to check the status of batch jobs in transaction SM37 and react to any unplanned termination. You also need to re-schedule the job manually. After a system crash, a batch job might remain in the status “running.” You can correct this in transaction SM37 by choosing Job ® Check status.
Whether you need to reschedule a periodic job does not depend on whether the job has successfully completed. A periodic job is rescheduled, if it starts at all, no matter what happens after the start. Apart from this, for periodic jobs with dedicated target hosts the same applies as for normal jobs with dedicated target hosts.
Automatic load distribution is performed for those batch jobs that are not scheduled on a dedicated host. A batch job that is not scheduled to run on a particular SAP NetWeaver ASinstance is sent to a dynamically chosen instance with a free batch work process.
For this reason we recommend you to configure several host machines with batch work processes. This avoids a singe point of failure (SPOF) for the batch service and makes it failure resilient. The SAP system automatically distributes work across the available batch work processes on the system.
Distinguish between host and server. In this context a host is a physical machine, and a server is an AS instance.
Several AS instances can run on one host.
You must schedule batch jobs relying on specific resources that are only accessible on a certain host by explicitly specifying the target host / target server.
To safeguard such jobs, install the dedicated AS instance on a cluster node that uses a virtual host name and switchover software for failure protection. We explain this approach in the section below.
If you take these precautions, job scheduling can survive a switchover. Scheduled batch jobs are started on the new host after a switchover without requiring manual intervention, assuming that the job was not already running at the time of failure. In this case the remarks made above in “Impact of Failure” apply.
The advantage of a batch service switchover is restricted to service resources that are relocated together with the SAP Web AS component, or resources that can also be accessed transparently from the new host machine.
If a printer batch job tries to access a printer that is not directly accessible from the new host machine after switchover, the job obviously fails. To avoid this problem with printers, do not attach them directly to a specific host machine. Instead provide printers with their own network connection that can be transparently accessed after host machine switchover. For more information on how to make spool services failure resilient, see Spool Service.
To schedule a batch job to run on a certain instance, you have to specify a server. The possible values are shown in the value help for the target field in transaction SM36.
To enable switchover, you have to set the host name and instance names on the switchover machine appropriately with virtual addressing, because the host or server name is used to start a job on the dedicated target.
With virtual addressing the user does not need to make any changes to a batch job after a switchover.
Note the following comments about SAP batch job scheduling and virtual host names and addresses:
? You schedule a batch job in SM36 and check whether the job has successfully completed in SM37.
? The host or server names that appear when you choose F4 for the target field in SM36 are retrieved from the message service. They can be local or virtual.
? The host or server name that you enter can be local or virtual.