Skip to content

TIME_OUT

The work process exceeded the maximum permitted runtime.

The ABAP kernel watchdog terminated the program because it ran longer than the system's configured time limit for dialog work processes. The entire LUW is rolled back.

Symptom

ST22 shows:

Runtime Errors         TIME_OUT
Short text             Time limit exceeded.

The dump line is wherever the program happened to be when the watchdog fired — usually inside a loop, a SELECT, or a called function module. It is not necessarily where the root problem is.

Cause

Dialog work processes (the ones handling user transactions) have a hard runtime limit, typically 300–600 seconds depending on the system profile. Background work processes have a much higher or no limit.

Common triggers:

  • A report or transaction unexpectedly processes far more data than normal (month-end load, data migration, bad filter).
  • A SELECT without a WHERE clause reads a table that has grown much larger since the program was written.
  • An infinite or near-infinite loop due to a logic error (missing exit condition, loop counter never incremented).
  • A WAIT UP TO N SECONDS accumulates inside a retry loop.
  • A deadlock or row-level lock causes a long blocking wait.

The time limit is a system parameter

The limit for dialog WPs is set by rdisp/max_wprun_time (default: 300 s on many systems). It can be raised for specific report variants via SE38 → Attributes → Runtime or globally in the instance profile. Raising it is a workaround, not a fix.

Reproduce

" Runs indefinitely in a dialog session — triggers TIME_OUT
DO.
  " missing exit condition
ENDDO.

Fix

The correct fix for heavy processing is always to schedule a background job. Background WPs are not subject to the dialog time limit.

" Schedule the same report via SM36, or trigger programmatically:
DATA: lv_jobname   TYPE tbtcjob-jobname   VALUE 'ZMY_JOB',
      lv_jobcount  TYPE tbtcjob-jobcount.

CALL FUNCTION 'JOB_OPEN'
  EXPORTING
    jobname  = lv_jobname
  IMPORTING
    jobcount = lv_jobcount.

CALL FUNCTION 'JOB_SUBMIT'
  EXPORTING
    jobname     = lv_jobname
    jobcount    = lv_jobcount
    report      = 'ZMY_REPORT'
    variant     = 'MY_VARIANT'.

CALL FUNCTION 'JOB_CLOSE'
  EXPORTING
    jobname          = lv_jobname
    jobcount         = lv_jobcount
    strtimmed        = abap_true.   " start immediately

" Before — reads everything, grows with the table
SELECT * FROM bkpf INTO TABLE @DATA(lt_docs).

" After — restrict to a meaningful range
SELECT * FROM bkpf
  INTO TABLE @DATA(lt_docs)
  WHERE bukrs = @lv_bukrs
    AND bldat >= @lv_date_from
    AND bldat <= @lv_date_to.

SELECT * FROM bkpf
  INTO TABLE @DATA(lt_chunk)
  PACKAGE SIZE 5000
  WHERE bukrs = @lv_bukrs.

  LOOP AT lt_chunk INTO DATA(ls_doc).
    " lightweight processing per row
  ENDLOOP.
ENDSELECT.

DATA lv_counter TYPE i.
DATA lv_max     TYPE i VALUE 100000.

DO.
  ADD 1 TO lv_counter.
  " ... processing ...

  " Safety exit — never allow unbounded loops
  IF lv_counter >= lv_max OR <done_condition>.
    EXIT.
  ENDIF.
ENDDO.

TIME_OUT cannot be caught

The watchdog terminates the work process externally — it does not raise a class-based exception. TRY ... CATCH blocks have no effect. The LUW is rolled back and control does not return to the program.

Prevention

  • All heavy processing (millions of rows, file imports, mass updates) belongs in background jobs, not dialog transactions.
  • Always add restrictive WHERE clauses and test with EXPLAIN / ST05 to verify index usage.
  • Use PACKAGE SIZE for bulk SELECTs that cannot be fully restricted.
  • Profile new programs with SAT before go-live to identify time-consuming statements.
  • Add loop safety counters to any DO ... ENDDO or WHILE without a guaranteed exit.

FAQ

Can I increase the time limit for a specific report? Yes — in SE38, open the report, go to Attributes → Runtime. You can set a higher limit for specific variants. For shared utility programs, use a background job instead.

The dump says TIME_OUT but the program only ran 30 seconds — why? The timer starts when the dialog work process receives the request, not when your ABAP code started. Long screen waits, PAI processing, and synchronous RFC calls all count toward the total.

See also

  • TSV_TNEW_PAGE_ALLOC_FAILED — memory overflow, often paired with heavy processing
  • DYNPRO_SEND_IN_BACKGROUND — related background job dump
  • Transaction SM36 — schedule background jobs
  • Transaction SM37 — background job log
  • Transaction SAT — ABAP runtime analysis
  • Transaction ST05 — SQL trace

Comments