Logs and dumps

When something goes wrong, two places tell you most of the story: the system log and the short dumps. First-level diagnosis means reading both quickly, connecting them by time, and deciding who owns the problem: Basis, the application team, development or SAP.

The system log: SM21

Each application server instance writes a system log of events and problems: database connection errors, work process terminations, failed logons, communication errors. Transaction SM21 shows it; by default it shows recent entries for the current instance, and you can select other instances to read them together. The log is a file of limited size, so old entries are overwritten silently. If you need entries from last week, read them before they are gone, or rely on central monitoring: Integration & Exception Monitoring in SAP Cloud ALM can collect ABAP runtime errors and system log entries from connected systems such as CMQ and CMP and keep them beyond the local file.

Short dumps: ST22

When an ABAP program hits a runtime error it cannot handle, the system terminates it and writes a short dump. Transaction ST22 lists dumps by date, user and program. Each dump states the runtime error name, a short text, what happened, where it happened (program, include, line), and the values of key variables. SAP training notes that dumps are kept for 28 days by default; mark an important one with Keep so housekeeping does not delete it.

Reading a dump in five minutes

1. Runtime error name, for example TIME_OUT or DBSQL_SQL_ERROR. Search SAP Notes with it.
2. What happened and error analysis: the plain-language description of the cause.
3. Information on where terminated: program, include and line. Custom programs start with Y or Z.
4. User and transaction: who ran what, in which client.
5. Time: then open SM21 for the same minute on the same instance to see what else happened.

When the dump and the log are not enough

Some problems leave no dump: a work process restarts, a connection hangs, a program behaves strangely without terminating. Then the developer traces help. Each work process writes technical trace files in the instance work directory (named dev_*), readable with ST11 or from the work process overview. They are verbose and technical, so read them around the time of the problem and look for errors. SAP also offers self-service tools such as Guided Answers and a support log assistant that analyzes uploaded logs and traces; use them before opening an incident, and attach the dump, the log extract and the traces when you do.