Background jobs are invisible right up until one fails during month-end close and three people are suddenly watching you troubleshoot it live. SM37 is where you start, but it rarely tells the whole story on its own.
Start in SM37, not the ticket
Pull up the job by name and date range and check its status first: Scheduled and Released mean it hasn't run yet; Ready means it's waiting for a free background work process; Active means it's running now; Cancelled is what you're here for. Open the job log before anything else — it almost always names the failing step.
The five most common cancellation causes
- ABAP runtime error. The job log references a short dump — go straight to
ST22and read it; the dump text usually names the exact statement that failed. - No free background work process. The job sat in Ready for a long stretch before cancelling. Check
SM50/SM66for work process saturation andRZ04for how many background processes the current operation mode allocates. - The job's user got locked or its password changed mid-run. A dialog user's password expiring under a scheduled job is one of the most common silent killers. Use a dedicated background/service user with a non-expiring password for anything scheduled.
- A missing or changed variant. Someone deleted or renamed the variant the job step points to. Check the Step tab in
SM37against what actually exists inSA38. - Authorization failure. The job runs under a user that's missing a role needed by that specific step.
SU53right after the failure, or anST01authorization trace if SU53 doesn't catch it, will show the missing object.
Reading the return code correctly
Don't conflate three different things that all get called "the RC": the job's overall status in SM37, the ABAP step's own return code, and — for jobs that call external programs like tp — that program's separate return code scale. Check the job log's return code first; it tells you which of the three you're actually looking at.
Cross-check the system log
SM21, filtered to the job's time window, catches what ABAP never reports to the job log at all — a full archive filesystem, a database connection drop, an OS-level resource limit. If ST22 shows nothing but the job still cancelled, this is the next place to look.
Preventing the next one
- Spread jobs across job classes A/B/C instead of scheduling everything for the top of the hour.
- Use a dedicated, non-expiring background user for scheduled jobs — never a named dialog user's ID.
- Monitor proactively with
RZ20/CCMS or an external monitoring tool, rather than waiting for the business to report a missed job. - For jobs that depend on each other, use event-based scheduling instead of fixed time gaps — a slow upstream job otherwise cancels the downstream one for "missing data" that was simply still being written.
FAQ
What does job status "Cancelled" mean in SM37?
It means the job started but didn't complete — it stopped partway through a step rather than finishing normally. The job log for that run names the step and, usually, the reason.
How do I find out why a background job failed?
Open the job log in SM37 first. If it points to a short dump, check ST22. If it shows nothing specific, check SM21 for the same time window for an OS or database-level cause ABAP wouldn't have reported.
Can a locked user cause a background job to fail?
Yes — if the user the job runs under gets locked, has its password expire, or loses a required role mid-schedule, the job cancels with an authorization or logon error even though nothing about the job itself changed.
No comments:
Post a Comment