SAP function moduleObjectJOB_SUBMITModuleABAP

JOB_SUBMIT — JOB_SUBMIT Function Module for Background Job Steps

JOB_SUBMIT adds one program execution step, with an optional variant, to a background job that has already been created by JOB_OPEN and not yet released by JOB_CLOSE. It does not start anything by itself. Every exception it returns must be checked, because an unchecked failure leaves a job open with fewer steps than the caller assumes, or with no steps at all.

This page covers how JOB_SUBMIT fits into the JOB_OPEN, JOB_SUBMIT, JOB_CLOSE sequence used to schedule background jobs from custom ABAP code. It focuses on the exceptions that get ignored in practice and the downstream symptoms in SM37 when they are.

Published 16 Sept 2026· 1,126 words

What it does

JOB_SUBMIT registers one executable step, an ABAP report plus an optional variant, against a job that has already been opened with JOB_OPEN. It must be called after JOB_OPEN and before JOB_CLOSE, and it can be called repeatedly to build a job with several sequential steps. JOB_SUBMIT does not release or schedule the job for execution; that happens only when JOB_CLOSE is called afterward with the required start conditions. It is a widely used part of the standard background processing API and appears in most custom scheduling programs that need to create jobs dynamically rather than through the job scheduling transaction. It is not a BAPI and has no transactional wrapper of its own; the job header and step tables are written directly.

Parameters

JOBNAME (importing) - the job name exactly as returned by the preceding JOB_OPEN call, not a freely chosen name at this point
JOBCOUNT (importing) - the job counter returned by JOB_OPEN, identifies the specific open job instance
REPORT (importing) - the ABAP program name to run as this step
VARIANT (importing, optional) - the variant name for the report; left blank if the report takes no variant or is called with selection screen defaults
LANGUAGE (importing, optional) - logon language under which the step runs, affects text elements and list output
AUTHCKNAM / USER (importing, optional) - the user whose authorizations are checked when the step executes; if left blank the calling user or job owner is used
ARCPARAMS (importing, optional) - archiving object parameters if the step's spool output should be archived automatically
STEP_NUMBER (exporting) - the sequential number assigned to the step just added, useful when a job has multiple steps and later processing needs to reference a specific one

Exceptions

BAD_PRIPARAMS - the print parameter structure passed for the step is invalid or inconsistent; the step is not added
BAD_XPGFLAGS - external program flags are invalid, relevant only for external command steps rather than ABAP report steps
INVALID_JOBDATA - the job header referenced by JOBNAME and JOBCOUNT is inconsistent or in a state that does not accept new steps
JOBNAME_MISSING - JOBNAME was passed blank, almost always a coding error where JOB_OPEN's output was never assigned
JOB_NOTEX - no job exists with the given name and count; typically means JOB_OPEN failed silently earlier, or the jobcount variable was overwritten before reaching this call
JOB_SUBMIT_ACTIVE - the job has already been released or started, so no further step can be added; usually caused by calling JOB_SUBMIT after JOB_CLOSE instead of before it
LOCK_FAILED - the job table could not be locked, usually a concurrency collision with another process touching the same job
PROGRAM_MISSING - REPORT was passed blank
PROG_ABAP_AND_VARIANT_SPECIFIED - conflicting step definition data was supplied
OTHERS - catch-all; when this is the only branch checked, the specific cause is lost and the resulting job either has no steps, has a step pointing at a nonexistent variant that fails only when it eventually runs, or never gets released because the calling program aborts JOB_CLOSE without cleanup

How to call it safely

Call JOB_OPEN first and capture JOBNAME and JOBCOUNT from its output, checking its own exceptions before proceeding. Call JOB_SUBMIT once per step, passing that same JOBNAME and JOBCOUNT, the REPORT, and VARIANT if needed, and check sy-subrc immediately after each call. If JOB_SUBMIT fails, do not call JOB_CLOSE as if nothing happened; either abandon the job or delete it explicitly, because an open job with a bad or missing step still sits in SM37 as scheduled and will either do nothing or dump when it runs. Only after every intended step has been submitted successfully should JOB_CLOSE be called with the start condition (immediate, date and time, or event) to actually release the job for execution.

ECC vs S/4HANA

JOB_SUBMIT remains a standard part of background processing in S/4HANA and continues to be used in custom scheduling code without a documented replacement. There is no clean-core restriction specific to this module beyond the general guidance to prefer released APIs over direct table access for job data; JOB_SUBMIT itself is the released API, not a workaround. Nothing about its parameter interface or exception behavior changes between ECC and S/4HANA as far as is documented; differences seen in practice usually trace back to job scheduler configuration or authorization changes rather than to the function module.

Common pitfalls

Ignoring the exception list and only checking sy-subrc against zero without inspecting which exception fired, which turns a variant typo into a job that silently does nothing rather than a caught error in the calling program
Reusing a JOBCOUNT value across loop iterations without reassigning it from a fresh JOB_OPEN call, which raises JOB_NOTEX or attaches steps to the wrong job
Passing a VARIANT name that does not exist for that report; JOB_SUBMIT itself does not validate the variant against the program's variant table in all cases, so the step gets created and then fails at actual execution time with an error that looks unrelated to the scheduling code
Calling JOB_SUBMIT after JOB_CLOSE has already released the job, which raises JOB_SUBMIT_ACTIVE and is usually a sign the program's control flow was restructured incorrectly during maintenance
Leaving AUTHCKNAM blank when the step needs to run under a specific service user, causing the step to execute under the job owner's authorizations instead and fail with an authorization short dump that has nothing obviously to do with the scheduling program

Whose problem this is

This is application development territory, not Basis. Whoever wrote the custom program that calls JOB_OPEN, JOB_SUBMIT, and JOB_CLOSE owns the exception handling and the consequences of skipping it. Basis owns job monitoring through SM37 and can confirm symptoms such as steps missing or jobs stuck in scheduled status, but tracing the root cause back to a swallowed exception is a development task.

Related objects

JOB_SUBMIT sits between JOB_OPEN and JOB_CLOSE in every dynamic job scheduling sequence and cannot be used meaningfully without both. The job header, step, and status data it writes live in the standard background processing tables commonly referred to as TBTCO, TBTCP, and TBTCS, which SM37 reads directly. Locking during concurrent job creation can surface through the same mechanisms exposed by enqueue and dequeue function modules when multiple processes attempt to modify the same job at once.

Related SAP objects

Reviewed pages this object connects to in the ERPClimb knowledge graph.

Source: ERPClimb — https://erpclimb.com/sap-function-modules/job-submitERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.