TBTCP table — Background Job Step Table TBTCP

One row in TBTCP represents a single step of a background job: an ABAP program with a variant, or an external command/program, scheduled as part of a job whose header lives in TBTCO. A job made of several chained steps, for example a data extraction report followed by a formatting program and a spool output step, produces one TBTCP row per step, numbered sequentially. The table records the definition of what runs and under which authorization, not the outcome. Whether the step succeeded, how long it took, or what its return code was is tracked at job level in TBTCO and in the job's execution log, not in TBTCP itself. Consultants read TBTCP when they need to isolate one step out of a multi-step job, most often to confirm the exact program and variant that actually ran, or to check under which user the step executed.

Always filter on MANDT and treat JOBNAME plus JOBCOUNT as the real key; JOBCOUNT by itself repeats across different job names and even across the same job name after redefinition. The table grows continuously in any system with meaningful batch volume, so selecting on PROGRAM or VARIANT alone across the full table is expensive and imprecise. The efficient path is to select the relevant job or jobs from TBTCO first, by name, status, or scheduled start window, and then read TBTCP restricted to those JOBNAME/JOBCOUNT pairs. Do not attempt to answer a timing question from TBTCP; it has no start or end timestamp fields.

Symptom: a completed job appears to have run the wrong variant. Take the JOBNAME and JOBCOUNT from the SM37 job list, select TBTCP where JOBNAME equals that job and JOBCOUNT equals that instance, order by STEPCOUNT, and read PROGRAM and VARIANT for each row. Compare against the expected variant. If the step instead failed with an authorization error, check AUTHCKMAN on the same row against the authorizations actually assigned to that user.

TBTCP is unchanged as a structural concept in S/4HANA. Background job scheduling continues to rely on TBTCO and TBTCP as the core header and step tables, including where the newer Fiori application job monitoring apps present a modernized interface; that interface reads through the same underlying job scheduling infrastructure rather than replacing these tables with a CDS view.

Basis owns TBTCP as part of background job administration and monitoring. Functional consultants use it read-only when chasing a specific step failure inside a multi-step job. Any question about cleanup, retention, or structural inconsistency between TBTCO and TBTCP belongs to Basis, not to the functional team running the job.

TBTCO is the job header table and the mandatory join partner for any TBTCP query. TBTCS holds the periodic scheduling definition referenced by jobs flagged as periodic. TSP01 and TSP03 hold the spool request and its attributes when a step produces printed or list output. BALHDR and BALDAT hold application log entries when a step's program logs through the application log. SM36 defines jobs and their steps, writing both TBTCO and TBTCP; SM37 is the primary transaction for reading them.