SAP ST22 Habit

A program terminated; you need to find and interpret the dump.

A short dump is what happens when an ABAP program hits a situation it cannot continue from and no code handles it. The runtime stops the program, rolls back the current database transaction, writes a detailed record of the state at the moment of failure, and shows the user a screen saying the transaction has been terminated. That record is the dump, and ST22 is where it is read.

Two things follow from the rollback that people get wrong. The work in the current transaction is gone, so nothing was half posted in the database. But anything already committed earlier in the same user session stands, and anything sent to another system stands too. So a dump does not mean nothing happened.

In ST22, select today’s (or the relevant) dumps, open the one matching the time/user, and read the structured sections: What happened, Error analysis, Source code extract, and the contents of variables and the call stack.

A dump is long and only about six things in it matter. Reading them in this order turns an intimidating screen into a diagnosis in a couple of minutes.

1. The runtime error name. This is the category, and it is the single most informative field. It tells you whether you are looking at a conversion problem, a missing entry, an authorisation issue or memory.
2. The short text. One line saying what happened in words.
3. The user, date and time. Which decides whether this is one user, one job, or everybody.
4. Where terminated. The program, include and line number. If it is a Z program you own it, and if it is standard SAP the next question is whether a note exists.
5. The source extract. The failing line with a few lines either side.
6. The variable contents. The values at the moment of failure, which is what turns "conversion failed" into "somebody typed a hyphen into a quantity field".

• The dump exists but is misread, focus on the error name and source line.
• Multiple dumps, pick the one matching the exact time/user/action.
• Standard-code dump, likely a known issue (SAP Note).
• Custom-code dump, an error in your program.

Where to look, before opening a single dump: the list itself. ST22 shows dumps by date, user and error name, and the shape of the list answers the first question. Many users and one error name means a data or configuration problem that everybody is hitting. One user and many error names usually means an authorisation or a master data problem specific to them. One job repeating on a schedule means something nightly is broken and nobody noticed.

A handful of runtime errors account for most of what appears in a real system, and recognising the name saves reading the rest.

Conversion errors. A value that will not go into the target type: text in a numeric field, an invalid date, an overflow. Almost always data rather than code, and the variable contents name the offending value.

Table entry missing. A read that expected a row and did not get one, in code that does not check. Configuration or master data, and the fix is usually in customising rather than development.

Division by zero. Exactly what it says, and it means a quantity or a divisor was zero in a case nobody anticipated.

Memory exhausted. The program asked for more than the profile allows. Sometimes a genuinely large selection, more often an internal table filled without a restriction.

Time limit exceeded. A dialog step ran past the limit. This is not a bug in itself, it is work that belongs in background processing.

Missing authorisation in a called object, and failed assertions or unhandled exceptions raised deliberately by code that decided it could not continue.

The reason to learn the names is that the fix differs completely between them, and the first four are usually somebody else's data rather than your code.

• Identify the runtime error name and failing statement.
• Inspect the variables/call stack for the trigger.
• For standard code, search SAP Notes by error + program.
• For custom code, reproduce and debug, then fix.

The decision worth making explicitly is whose problem it is, because it changes who does the work. Three outcomes.

Data. The code is correct and the input was not. Correct the record, and then decide whether the program should have handled it gracefully. Many should: a dump is a poor way to tell a user that a field is wrong.

Configuration. A missing customising entry. The fix is in the configuration transport, not in development, and the same dump will appear in every system that lacks the entry.

Code. Yours to fix, or SAP's. For standard SAP, search for a note using the runtime error name and the program, because the odds are good that somebody met it first. Modifying standard code to stop a dump is a last resort and it is met again at every upgrade. See the ST22 transaction reference.

One more thing to establish before deciding anything: whether the dump is reproducible. A dump you can trigger on demand in a test system is a straightforward problem. A dump that happened once, under load, at month end, with data that has since been corrected, may not be worth chasing beyond recording it. Saying so explicitly is better than an open investigation nobody closes.

Make ST22 a habit: reviewing dumps regularly catches problems early. Recurring custom-code dumps signal code that needs fixing; recurring standard dumps signal a missing Note or configuration issue.

Two habits do most of the work. Check before you read: a subroutine that reads a table and assumes a row exists is one unusual record away from a dump, and handling the empty case is one line. And make failures visible: a dump inside a background job is invisible in the job log, so without somebody checking the dump list a failing nightly job looks fine for weeks. See job failures.

Worth knowing about retention: dumps are deleted by a standard reorganisation job after a period that is often quite short. So a dump reported today may already be gone by the time somebody looks, and the useful instruction to give a user is to send the runtime error name and the timestamp rather than a description of the screen.

• Guessing instead of reading the log/dump.
• Fixing the symptom, not the root cause.
• Changing several things at once.

• Reading the stack before the error name. The name is the diagnosis.
• Fixing the symptom in standard code. Check for a note first.
• Assuming one dump means one problem. Sort the list and see whether it is one user, one job, or everyone; that shape is most of the answer.
• Ignoring dumps that did not stop anything. See performance troubleshooting.

Version note: the transaction and the dump layout are the same on ECC and S/4HANA, and on newer releases the same information is also reachable through the monitoring applications. The reading order above does not change.

Reading a dump is half an hour, and knowing which of the three outcomes you are looking at without guessing is what the course builds.