JOB_OPEN — Opening a background job for step submission
JOB_OPEN is a released function module that creates a new background job entry and returns a JOBCOUNT identifying it. It is the mandatory first step before attaching program steps with JOB_SUBMIT and releasing the job with JOB_CLOSE. Failing to check its return code, or never calling JOB_CLOSE afterward, leaves orphaned jobs stuck in 'Scheduled' status in SM37.
This page covers JOB_OPEN, the function module that initiates a background job instance and hands back the JOBCOUNT needed for every subsequent step. It focuses on the exceptions that get swallowed in practice, the orphan-job pattern that clutters SM37, and how the call fits into the JOB_OPEN / JOB_SUBMIT / JOB_CLOSE sequence.
Published 16 Sept 2026· 891 words
What it does
JOB_OPEN creates a new entry in the background job control tables and returns a JOBCOUNT that, combined with the job name supplied by the caller, uniquely identifies the job instance for the rest of its life. It does not schedule anything and does not attach any executable step; it only reserves the job slot. It is released for customer use and is the standard entry point for any custom logic that needs to schedule a report, function module step, or external command as a background job at runtime rather than through SM36. The job created by JOB_OPEN sits in 'Scheduled' status and stays there until JOB_CLOSE is called against the same JOBCOUNT and job name, or until it is deleted.
Parameters
- JOBNAME (importing, required) - the name to assign to the job, up to 32 characters, must not be blank; together with the returned JOBCOUNT this forms the job's unique key for the whole lifecycle
- DELANFLAG (importing, optional) - flag indicating the job should be automatically deleted from the job overview once it completes successfully; default is space, meaning the job stays visible in SM37 after completion
- JOBGROUP (importing, optional) - used to associate the job with a job group for grouped scheduling scenarios; rarely populated by ordinary callers
- JOBCOUNT (exporting) - the eight-digit job counter generated by the call; this value must be captured and passed unchanged to every following JOB_SUBMIT and to the closing JOB_CLOSE call for this job instance
Exceptions
- CANT_CREATE_JOB - the job entry could not be inserted, typically because of a technical problem creating the job control record or an internal collision; if this is swallowed the code continues with an initial or garbage JOBCOUNT, and the following JOB_SUBMIT call either fails outright or, worse, attaches the step to an unrelated existing job
- INVALID_JOB_DATA - the job name violates naming rules, for example it is blank, contains disallowed characters, or exceeds the length limit; ignoring this produces the same downstream failure, an unusable JOBCOUNT that later calls cannot work with
- JOBNAME_MISSING - the JOBNAME parameter was not supplied at all; this is a programming error in the caller and should never occur in a properly written wrapper, but if the exception is not handled the call simply returns without a usable job
How to call it safely
The call is exporting jobname, optionally delanflag, importing jobcount, with the exceptions listed explicitly rather than caught under a generic others. After the call, check sy-subrc and, independently, verify that the returned jobcount is not initial before doing anything else. Only after that check should the code proceed to JOB_SUBMIT for each step and finally JOB_CLOSE to release the job for execution. Treat the three calls as one atomic unit of work in the calling program; if an error occurs between JOB_OPEN and JOB_CLOSE, the opened job should be actively cleaned up rather than left dangling.
ECC vs S/4HANA
JOB_OPEN remains valid and unchanged in S/4HANA. There is no clean-core restriction on it and no newer released function module that replaces the classic JOB_OPEN / JOB_SUBMIT / JOB_CLOSE trio for dynamic background job creation from ABAP. Extension developers building on the ABAP Cloud restricted programming model should still favor released APIs for scheduling where available, but for on-stack or classic extensions this remains the standard mechanism.
Common pitfalls
- Not checking sy-subrc after JOB_OPEN and proceeding with an empty jobcount, so JOB_SUBMIT either raises its own exception or, in the worst case, silently does nothing
- Opening a job and then aborting the program (dump, timeout, missing exception handling) before JOB_CLOSE is reached, leaving the job permanently in 'Scheduled' status in SM37 with no steps ever executed
- Calling JOB_OPEN repeatedly inside a loop for many small jobs without closing each one immediately, which produces dozens of orphan jobs that Basis eventually has to clean up manually
- Reusing a fixed, hardcoded job name across parallel processes or repeated runs, which does not itself fail but makes the resulting jobs indistinguishable in SM37 and complicates monitoring and restart logic
- Assuming DELANFLAG deletes the job immediately after JOB_OPEN; it only takes effect after the job has actually run and completed successfully
Whose problem this is
Ownership sits with the developer or the custom application that dynamically creates the background job. Basis gets pulled in only when the symptom surfaces as orphaned jobs stuck in 'Scheduled' status in SM37, at which point the fix belongs back with the application code that opened the job and never closed or deleted it.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-function-modules/job-openERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.