TBTCS table — Background Job Status Text Table

One row in TBTCS represents a single background job status code together with its descriptive text in one language. Background jobs carry an internal one-character status code on the job header (values such as scheduled, released, ready, active, finished, and cancelled or aborted). Rather than hardcoding the text for each status in every screen and report, the status field is looked up against this table so that SM37, job logs, and custom monitoring reports can render the status in the user's logon language. Because the set of possible statuses is fixed and small, this table has a low, static row count: the number of defined status codes multiplied by the number of installed logon languages. It does not grow with job execution volume and is not a place to look for job history or scheduling data.

This is a client-independent or near-static customizing table, not a client-dependent transactional one, so there is no meaningful selectivity discussion the way there would be for TBTCO or TBTCP. The only sensible restriction is on the status code and the language key, and even without any restriction the table returns at most a few dozen rows per language. If a query against it returns thousands of rows, the join condition is wrong, most likely joined on job name or job count instead of status.

To confirm what a status code seen in a job header actually means in a given language, select TBTCS restricting on STATUS equal to the code found in TBTCO-STATUS for the job in question, and SPRAS equal to the language of interest. The single row returned gives the text that SM37 would display for that job in that language. If no row comes back, the status value itself is suspect, not the text table.

TBTCS is part of the standard background processing infrastructure and is not a Basis area that S/4HANA restructured. Background job scheduling, execution, and status handling work the same way on S/4HANA as on ECC, so the table's shape and purpose are unchanged. There is no compatibility view replacing it and no indication it has been deprecated in favor of a newer object.

Any question that actually needs answering here belongs to Basis, since it concerns the job scheduling infrastructure rather than application data. In practice this table is rarely a focus of investigation on its own; Basis looks at it only in passing while diagnosing a status display issue in SM37, with the real analysis centered on TBTCO and TBTCP.

TBTCO holds the job header including the status code this table translates, written whenever a job is scheduled, released, started, or finishes through SM36 and SM37. TBTCP holds the individual job steps and their outcomes. Spool output produced by a job's steps is tracked through TSP01 and TSP03, and application log entries a job writes can be found via BALHDR and BALDAT. None of these tables are joined directly to TBTCS except through the shared status code convention.