Background jobs run without interactive input: overnight batches, scheduled interfaces, long aggregations.
Why they are needed
- Dialog processing has a runtime limit
- Heavy processing is better run outside business hours
- Recurring work runs unattended
- Execution history and logs are retained
Defining a job
| Element | Content |
|---|---|
| Job name | The identifier; adopt a naming convention |
| Job class | A, B or C โ priority |
| Steps | Programs or external commands to run |
| Variant | Selection values passed to the program |
| Start condition | When it runs |
| Target server | Which instance executes it |
Start conditions
| Condition | Behaviour | Use |
|---|---|---|
| Date and time | At a scheduled moment | Nightly routines |
| Immediate | Right away | Ad hoc long processing |
| After job | When a predecessor finishes | Enforcing sequence |
| Event | When an event is raised | Triggered externally |
| Operation mode | On a mode switch | Tied to operating windows |
Variants
Monitoring
| Status | Meaning |
|---|---|
| Scheduled | Defined but with no start condition |
| Released | Ready to run |
| Ready | About to start |
| Active | Running |
| Finished | Completed normally |
| Cancelled | Terminated; check the log |
When a job does not run
| Cause | How to check |
|---|---|
| No free background processes | SM50 for BTC availability |
| Job not released | SM37 status |
| Insufficient authorisation | The job log in SM37 |
| The run user is locked | SU01 |
| Target server down | SM51 |
| Operation mode gives no BTC processes | RZ04 |