Debugging Part 6: ST22 Short Dump Analysis

📌 KEY POINTS
✅ ST22 shows every runtime error with name (e.g. CONVT_NO_NUMBER), exception class (CX_SY_CONVERSION_NO_NUMBER), program, line, user and time.
✅ Read in this order: short text → "What happened" / "Error analysis" → "Source code extract" (the failing line) → "Active calls" (call stack) → "Chosen variables".
✅ "Debugger" button (for recent dumps in some cases) or reproducing with a breakpoint at the failing line gives the full context.
⚠️ A dump in SAP standard code is often caused by custom data or exits (e.g. wrong values passed) — check the call stack for Z code before opening an SAP incident.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Parts 2–5 debugged running code. When a program terminates, ST22 is the starting point.

━━━━━━━━━━━━━━━━━━━━
▶ 1. FINDING THE DUMP
ST22 → select by date, user, program; dumps are kept for a limited time (default about 14 days).

━━━━━━━━━━━━━━━━━━━━
▶ 2. SECTIONS

• Short text and runtime error: category of the problem.
• What happened / What can you do: general explanation.
• Error analysis: specifics (e.g. "the value 'ABC' cannot be interpreted as a number").
• How to correct: SAP's hints; search SAP notes by runtime error + program.
• Source code extract: the failing statement marked with >>>.
• Active calls/events: the call stack — find the first custom program.
• Chosen variables: values at the dump time.

━━━━━━━━━━━━━━━━━━━━
▶ 3. COMMON DUMPS

• CONVT_NO_NUMBER / CX_SY_CONVERSION_NO_NUMBER: text into numeric field → validate/convert input.
• BCD_ZERODIVIDE: division by zero → check divisor.
• TSV_TNEW_PAGE_ALLOC_FAILED / memory: huge internal tables → packages, selective reads.
• GETWA_NOT_ASSIGNED: field symbol not assigned → IS ASSIGNED check.
• DBSQL_* / SAPSQL_*: invalid SQL (e.g. empty FOR ALL ENTRIES consequences, too many values, wrong types).
• ITAB_DUPLICATE_KEY: insert duplicate into unique table.
• TIME_OUT: dialog step exceeded rdisp/max_wprun_time → run in background or optimize.
• MESSAGE_TYPE_X: deliberate abort (MESSAGE X) — read the message and caller.
• RAISE_EXCEPTION / UNCAUGHT_EXCEPTION: exception not caught → add handling.

━━━━━━━━━━━━━━━━━━━━
▶ 4. FIX PATTERN
Understand the data that triggered it → fix code (validation, TRY/CATCH, guards) or data → test with the same data.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

1. Run the code example to create a controlled dump in a sandbox.
2. Analyse it in ST22 section by section.
3. Fix with TRY/CATCH and rerun.

✅ CHECKPOINT: you can read ST22 dumps and derive the root cause quickly.

A nightly interface dumped with CONVT_NO_NUMBER in a standard function module. The team was about to open an SAP incident, but the "Active calls" section showed a Z mapping program passing a quantity field containing "1,5" (comma decimal) from a partner file.
Adding input normalisation in the mapping and a TRY/CATCH with a clear error log fixed the issue without SAP support.

• Reading only the short text.
• Assuming SAP code is at fault without checking the call stack.
• Ignoring chosen variables.
• Fixing by catching everything (CX_ROOT) silently.
• Not reproducing with the same data.

• Read ST22 section by section.
• Find the first custom program in the call stack.
• Use error analysis and variables for root cause.
• Catch specific exceptions with meaningful messages.
• Search SAP notes by runtime error and program.

Questions: "How do you analyse a short dump?", "Name common dumps and causes.", "A dump occurs in SAP standard code — what do you do?"
Strong answer: ST22 sections: runtime error/exception class, error analysis, source extract, active calls, variables; common: CONVT_NO_NUMBER, BCD_ZERODIVIDE, TSV_TNEW_PAGE_ALLOC_FAILED, GETWA_NOT_ASSIGNED, ITAB_DUPLICATE_KEY, TIME_OUT, MESSAGE_TYPE_X, UNCAUGHT_EXCEPTION; check call stack for Z code, SAP notes; fix with validation/TRY-CATCH.