TBTCO table — Background Job Header Table
TBTCO holds one row per background job instance: job name, job number (JOBCOUNT), status code, scheduled versus actual start and end timestamps, the authorization user, and event or periodic flags. It does not hold job steps, print parameters, or spool content — those live in TBTCP, TBTCS, and TSP01/TSP03. Use it to prove when a job ran, how long it ran, and what status it ended in.
TBTCO is the header table behind every background job shown in SM37, one row per job name plus job count. This page covers the fields worth trusting, the joins to job steps and spool, and the recurring mistakes made when reading job status and timing off this table during an incident.
Published 15 Sept 2026· 999 words
What it stores
One row in TBTCO represents a single instance of a background job as scheduled or executed on the system - identified by the combination of job name and an eight-digit job count assigned by the kernel. The row carries the job's lifecycle: when it was scheduled to start, when it actually started and ended, its current status, the user under whose authorization it runs, and whether it is event-driven or periodic. It does not contain the individual steps of the job (program, variant, print list), which live in a separate step table, nor the spool output the steps generate. A periodic job produces a new TBTCO row for every run; the row for a finished job is eventually purged by housekeeping, so the table is a live operational record, not a permanent archive.
Key fields
- MANDT - client
- JOBNAME - name of the background job as defined in SM36
- JOBCOUNT - eight-digit job number; together with JOBNAME uniquely identifies one job instance
- STATUS - single-character job status (P scheduled, S released, Y ready, R running, F finished, A aborted)
- SDLSTRTDT / SDLSTRTTM - scheduled start date and time
- STRTDATE / STRTTIME - actual start date and time
- ENDDATE / ENDTIME - actual end date and time
- AUTHCKNAM - user under whose authorization the job executes
- EVENTID - background event name that triggers the job, if event-driven
- PERIODIC - flag marking the job as set to repeat
How it joins the data model
- TBTCO-JOBNAME = TBTCP-JOBNAME and TBTCO-JOBCOUNT = TBTCP-JOBCOUNT - one row per job step, holding program, variant, print parameters and spool identifier
- TBTCO-JOBNAME = TBTCS-JOBNAME - the periodic job definition that regenerates a fresh TBTCO/TBTCP pair on every run
- TBTCP-LISTIDENT = TSP01-RQIDENT - spool request created by a job step's list output
- Application log handle referenced from a job step can be looked up as BALHDR-LOGNUMBER, with BALDAT holding the log content
How to read it safely
Always restrict on MANDT and JOBNAME first; JOBCOUNT alone is meaningless without a job name, and STATUS alone is not selective on a mature system with millions of historical rows. Add a date range on SDLSTRTDT or STRTDATE before running anything ad hoc against this table, otherwise the select scans far more than intended and either times out or locks up shared memory during peak batch windows. Do not expect long-term history: finished job rows are removed by periodic job log cleanup, so absence of a row is not proof a job never ran, only that its record has aged out.
How to prove it in the data
Symptom: a job looks stuck in SM37. Select TBTCO where JOBNAME equals the job and STATUS equals 'R', read STRTDATE/STRTTIME as the actual start, and compare elapsed time against the current system clock. Then check the corresponding TBTCP row to see which step is active, and confirm against the work process monitor whether a process is genuinely still assigned to that job count. If no process matches, the STATUS='R' row is stale, not a live job.
ECC vs S/4HANA
TBTCO exists unchanged in role on S/4HANA - it remains the kernel-level header table for background job control in both ECC and S/4HANA, and its structure and meaning are stable across releases. Fiori-based job monitoring applications read job data through standard scheduling APIs rather than direct SQL against this table, but the underlying storage and field semantics have not been replaced by a CDS compatibility view. Treat any release-specific behavioral difference as a Basis kernel question, not a data model change.
Common pitfalls
- STATUS='R' does not guarantee the job is alive - after a work process crash or system restart the header can remain stuck at 'running' indefinitely; cross-check the work process table before reporting a hung job, otherwise the conclusion is wrong from the start.
- Confusing SDLSTRTDT/SDLSTRTTM (what was scheduled) with STRTDATE/STRTTIME (what actually happened) leads to blaming the job definition for a delay that was actually caused by a shortage of free background work processes at the scheduled time.
- JOBCOUNT is a unique kernel-assigned number, not a chronological sequence across job names - sorting by JOBCOUNT alone does not reconstruct the order in which different jobs ran.
- Absence of historical rows for a job name is often housekeeping deletion of old job logs, not evidence the job stopped running - check retention settings before concluding a scheduling failure.
- A TBTCO row is one instance of a periodic job, not the periodic definition itself; deleting or manually changing that row has no effect on future runs, which are controlled from TBTCS.
- AUTHCKNAM usually shows a technical or batch user, not the person who originally scheduled the job - attributing an authorization failure to the wrong person is a common misread of this field.
Whose problem this is
Background job scheduling, monitoring, retention housekeeping, and any question about why a job started late or is stuck belongs to Basis. Functional consultants query TBTCO only to prove timing and status when a batch report or interface job is under investigation - they should not be changing status or deleting rows directly.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/tbtcoERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.