ABAP programs are checked statically when they are created and dynamically when they are running. Error states, which are not statically predictable and only occur at runtime are dynamically identified by the ABAP runtime environment. States of this type lead to exceptions. If an exception is not handled or cannot be handled, a runtime error occurs. If a runtime error occurs, the ABAP runtime environment terminates the execution of the program, generates a short dump and branches to a special screen for analyzing the short dump. You can also find short dumps in transaction ST22
or by choosing the menu path Tools → ABAP Workbench → Test → Dump Analysis.
A short dump is divided into different sections that document the error. The overview shows what other information is output in the short dump, such as contents of data objects, active calls, control structures, and so on. You can branch to the ABAP Debugger at the termination point from the short dump view. The following different error situations exist:
A short dump is divided into different sections that document the error. The overview shows what other information is output in the short dump, such as contents of data objects, active calls, control structures, and so on. You can branch to the ABAP Debugger at the termination point from the short dump view. The following different error situations exist:
. Internal Error
The kernel identifies an error state. In this case, notify SAP.
. Installation and Environment/Resource Error
In this case, an error occurred that was caused by incorrect system installation or
missing resources (such as the database being shutdown).
. Error in Application Program
Typical causes of errors are:
. Content of a numerical field not in the correct format
. Arithmetic overrun
. An external procedure is not available
. Type conflict when transferring parameters to an external procedure
By default, short dumps are stored in the system for 14 days. The transaction for managing short dumps is ST22. You can delete short dumps in accordance with a time specification using the Reorganize function, which you can call by choosing Goto → Reorganize. You can save a short dump without a time limit using the Keep function, which you can choose under Short Dump → Keep/Release.
If problems that you cannot solve yourself occur with ABAP programs, you can send an extract of the short dump to SAP. A short dump is the basis on which the SAP Hotline and remote consulting solve problems.
. If a runtime error occurs, a short dump is generated. You can use transaction ST22 to analyze this short dump.
. Dump data is stored in the database.
. Dump data can be reorganized.
. Individual short dumps can be flagged for retention.
SAP System Trace
. Installation and Environment/Resource Error
In this case, an error occurred that was caused by incorrect system installation or
missing resources (such as the database being shutdown).
. Error in Application Program
Typical causes of errors are:
. Content of a numerical field not in the correct format
. Arithmetic overrun
. An external procedure is not available
. Type conflict when transferring parameters to an external procedure
By default, short dumps are stored in the system for 14 days. The transaction for managing short dumps is ST22. You can delete short dumps in accordance with a time specification using the Reorganize function, which you can call by choosing Goto → Reorganize. You can save a short dump without a time limit using the Keep function, which you can choose under Short Dump → Keep/Release.
If problems that you cannot solve yourself occur with ABAP programs, you can send an extract of the short dump to SAP. A short dump is the basis on which the SAP Hotline and remote consulting solve problems.
. If a runtime error occurs, a short dump is generated. You can use transaction ST22 to analyze this short dump.
. Dump data is stored in the database.
. Dump data can be reorganized.
. Individual short dumps can be flagged for retention.
SAP System Trace
You can use the system trace to record internal system activities. The system trace is primarily used if an authorization trace is to be created. SAP recommends that you use the system log or the developer trace for system monitoring and problem analysis.
You can call the SAP System Trace using transaction ST01 or by choosing the menu path Tools → Administration → Monitor → Traces → System Trace. You can also use transaction ST01 to display the inactive trace file.
You can use the SAP system trace to monitor the following components:
. Authorization checks
. Kernel functions
. Kernel modules
. DB accesses (SQL Trace)
. Table buffers
. Lock operations (client-side)
You select the components to be logged on the initial screen. If the trace is activated for the authorization check, all authorization checks performed by the system are recorded. During the evaluation, you can identify which authorizations the system checked at which times. The following detail information is also provided: Date, time, work process number, user, authorization object, program, line, number of authorization values, authorization values.
You can use the SQL Trace to follow how the Open SQL commands in reports and transactions are converted to standard SQL commands and the parameters with which the SQL commands are transferred to the database system in use. The results of the SQL command are also logged, such as the return code and the number of records found, inserted, or deleted by the database. Logging the execution time and the callpoint in the application program allows you to perform more advanced evaluations.
With the enqueue trace, you can follow which lock instructions the SAP system performs on which lock objects, and which parameters the system uses for these locks.
The program that triggered the lock, the owner of the lock, and the time that the enqueue server required to release the lock again are all also logged in the trace file.
You can use the RFC trace to follow which remote calls the SAP system executes, and the instance on which these calls are executed. You can see from the trace which function modules were called remotely by the program that is to be analyzed, and whether the RFC was successfully executed. The total time required for the execution of the remote call and the number of bytes sent and received during the RFC are also logged in the trace file.
