ST22 Short Dump Analysis

Explanation

ST22 is used to analyze ABAP runtime errors, commonly called dumps. A dump contains the runtime error, exception, program, include, line number, user, transaction, call stack and variable details. A junior developer may jump directly to the line number, but a senior consultant reads the full context: what happened, which user and transaction triggered it, what input data caused it, whether it happened once or repeatedly, and what code path led to it. Common dumps include conversion errors, field symbol not assigned, internal table access error, memory issues and database exceptions. ST22 analysis is essential for production support.

Code example

* Example risky conversion:* If LV_AMOUNT_TEXT contains non-numeric text, this can dump. DATA lv_amount TYPE wrbtr. lv_amount = lv_amount_text. * Safer pattern:* Use TRY CATCH to handle conversion issue gracefully. TRY.    lv_amount = CONV wrbtr( lv_amount_text ).  CATCH cx_sy_conversion_no_number INTO DATA(lx_conv).    * Log bad input instead of causing uncontrolled short dump    APPEND VALUE #( type = 'E'                    message = 'Invalid amount format' ) TO gt_return.ENDTRY. * ST22 tells you:* runtime error, program, line number, user, transaction and call stack.

Real project scenario

A month-end job dumps with CONVT_NO_NUMBER. ST22 shows a blank amount field was passed to numeric conversion. The fix is to validate input before conversion and log bad records.

Common mistakes

- Looking only at dump line and ignoring call stack. - Not checking user/input values. - Fixing symptom without root cause. - Not checking whether dump repeats.

Best practices

- Read full dump context. - Check user, transaction and input. - Analyze call stack. - Identify root cause before code fix. - Add validation for bad data.

Interview angle

A strong support answer explains how to use ST22: runtime error, source line, variables, call stack and reproduction data.