JOB_CLOSE — JOB_CLOSE Function Module Reference
JOB_CLOSE is the final call in the standard background job creation sequence (JOB_OPEN, JOB_SUBMIT, JOB_CLOSE). It releases a job that was opened and had at least one step submitted, applying the start condition (immediate, scheduled time, predecessor job, or event). It is released for customer use and RFC-enabled. Calling it on a job with no steps or a mismatched jobcount produces a job that never runs.
This page covers JOB_CLOSE, the function module that finalizes and releases a background job created via the JOB_OPEN and JOB_SUBMIT sequence. It focuses on the exceptions that are routinely swallowed, the orphaned or empty jobs that result, and the call discipline required to avoid silent scheduling failures.
Published 16 Sept 2026· 1,076 words
What it does
JOB_CLOSE closes a background job definition that was created with JOB_OPEN and populated with one or more steps via JOB_SUBMIT. Closing does not just end the definition phase, it actively releases the job into the scheduler according to the start condition parameters passed in the same call: immediate execution, a fixed date and time, a predecessor job, a factory-calendar workday rule, or an event. It is released for customer use and is RFC-enabled, so it is commonly called from both local ABAP and remote systems that need to trigger background processing on a target instance. Without a successful JOB_CLOSE call, a job opened via JOB_OPEN remains in a scheduled-but-not-released state and never executes, regardless of how many steps were submitted to it.
Parameters
- JOBCOUNT (import, mandatory) - the eight-digit job number returned by the preceding JOB_OPEN call, must match exactly
- JOBNAME (import, mandatory) - the job name used to open the job, must match the name passed to JOB_OPEN
- STRTIMMED - flag requesting immediate start once the job is released
- SDLSTRTDT and SDLSTRTTM - scheduled start date and time when the job is not started immediately
- PRDDAYS, PRDHOURS, PRDMINS, PRDWEEKS, PRDMONTHS - periodic recurrence interval values
- PRED_JOBNAME, PRED_JOBCOUNT, PREDJOB_CHECKSTAT - predecessor job chaining and status check
- EVENTID, EVENTPARM - event-triggered start
- TARGETSYSTEM - application server or instance the job should run on
- CALENDAR_ID - factory calendar used for periodic or workday-based scheduling
- LASTSTRTDT, LASTSTRTTM - latest permitted start date and time
Exceptions
- JOB_NOTEX - the JOBNAME/JOBCOUNT pair does not identify an open job; usually caused by passing the wrong jobcount, or trying to close a job that another process already closed or deleted
- JOB_NOSTEPS - the job has no steps because JOB_SUBMIT was never called or its return code was ignored after a failure; the job still gets closed as an empty shell that runs no program and produces no log entry, so nothing appears to have failed
- JOB_CLOSE_FAILED - a generic close failure, often an inconsistent job header, an authorization gap, or the job already in a state that cannot transition to scheduled
- CANT_START_IMMEDIATE - immediate start was requested but could not be honored, typically because no background work process is free or the start condition conflicts with immediate execution
- INVALID_STARTDATE - the scheduled date and time are invalid, already in the past, or inconsistent with the periodic parameters supplied
- INVALID_TARGET_SYSTEM - the named target system is not defined in the RFC/logon group landscape
- LOCK_FAILED - the job object could not be locked for closing, usually a concurrency collision on the same job number
- OTHERS - catch-all; swallowing this with a blank ELSE branch is the single most common cause of jobs that a program believes it scheduled but that never appear in SM37
How to call it safely
The call sequence is fixed: JOB_OPEN returns JOBCOUNT, one or more JOB_SUBMIT calls attach ABAP report or external command steps to that jobcount, then JOB_CLOSE is called with the same JOBNAME and JOBCOUNT plus the desired start condition. Every call in the chain must have its sy-subrc and exception checked before proceeding to the next; a program that calls JOB_SUBMIT without checking its result and then unconditionally calls JOB_CLOSE risks releasing a job with zero steps. After JOB_CLOSE returns, verify sy-subrc is zero and, where the job is critical, re-read the job status from the job header table to confirm it moved from 'scheduled' to the expected release state rather than trusting the function's return code alone.
ECC vs S/4HANA
JOB_CLOSE is unchanged core background-processing functionality and remains fully valid on S/4HANA; it is not deprecated and has no dedicated successor function module. It sits below the level of the digitization and clean-core initiatives, since it is kernel-adjacent scheduling infrastructure that SAP's own reports and jobs rely on internally. For new custom development, particularly anything intended to run in a clean-core or cloud ABAP environment, released higher-level job scheduling APIs and Fiori-based job management are the preferred entry point, but classic on-premise and hybrid landscapes continue to call JOB_OPEN, JOB_SUBMIT and JOB_CLOSE directly without restriction.
Common pitfalls
- Calling JOB_CLOSE after a JOB_SUBMIT failure that was not checked, producing a released job with no steps that silently does nothing and leaves no trace of error
- Passing a JOBCOUNT that does not match the one returned by JOB_OPEN, raising JOB_NOTEX and aborting the whole scheduling attempt after the job header was already created
- Setting STRTIMMED without also setting the periodic interval fields when a recurring job is intended, resulting in a single immediate run instead of a repeating schedule
- Ignoring the OTHERS exception branch, so a JOB_CLOSE_FAILED or LOCK_FAILED condition is never surfaced and the calling program logs a false success
- A program crash or short dump between JOB_OPEN and JOB_CLOSE leaves an orphaned job stuck in 'scheduled' status indefinitely, cluttering the job overview until cleaned up manually or by a periodic job-deletion report
- Concurrent processes reusing the same job name without coordinating jobcounts, leading to intermittent JOB_NOTEX or JOB_CLOSE_FAILED errors under load that are hard to reproduce outside peak periods
Whose problem this is
Correct use of the JOB_OPEN, JOB_SUBMIT, JOB_CLOSE sequence is the responsibility of whoever writes the custom program creating the job; a job that never runs because of a swallowed exception is a development defect, not an infrastructure fault. Basis owns the background processing infrastructure itself, including stuck or orphaned scheduled jobs, work process availability for immediate starts, and target system definitions used by TARGETSYSTEM.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-function-modules/job-closeERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.