ABAP ‘short dump’ (German Kurzdump) is a misnomer. There is nothing ‘short’ about an ABAP dump. Should the ABAP AS no longer be able to execute a program – because of an unhandled or unhandleable exception, a resource or system problem, or an error in coding – it may document the problem with 20 or more pages of diagnostic information.
Very often, a short dump contains not only the exact diagnosis of the problem that occurred but also the solution, or at least important pointers toward the solution of the problem. But experience has shown that developers often don’t even read dumps – not even the highly useful Error analysis – much less make use of the diagnostic resources that short dumps offer.
The lack of attention to short dumps is understandable but regrettable.
Understandable because the report that your program is dumping in a customer system is about the worst news you can get. It’s time to drop everything and switch to emergency mode.
Regrettable, because often developers who don’t take a good look at the short dump waste a lot of time thrashing around in the debugger, trying to understand what went wrong. Taking a good look at the short dump is usually a better use of your time. And then there are the situations in which the dump is the only diagnostic resource that you have – when the dump occurred in a production system and is too sensitive to repeat, when the dump occurred several hours after the background job started, and so on.
In this pair of weblogs, we will take a quick tour through the ABAP short dump as of NetWeaver Release 7.0 EHP1, pointing out important analytic aids that it offers and how to make the best use of them.
In the first weblog, we will just get ready to analyze a dump. The weblog looks at the ABAP dump lists and how to get the most out of them, as well as at a couple of related sources of information.
Off to the Dump
If you aren’t staring at a short dump on the screen in front of you, then the way to see any ABAP short dumps in your system is by starting transaction ST22. As standard selections, ST22 lets you list dumps from yesterday and today, but also lets you select dumps by user, date and other parameters.
Adding Information to the List of Selected Runtime Errors
It is natural to want to hurry right to the display of a dump that you need to investigate. But hold on – have you ever noticed those three useful little options at the bottom of the ST22 start screen? You might want to take a look at them before you rush off into a list of short dumps.
By default, the options are not set. But:
With information on Exception/Short Text of Runtime Error extracts the data provided by the exception object, if a class-based exception triggered the dump. The display of the exception object may show you useful information, such as the exception’s error message. If the initial exception was caught by another exception, then you can see the chain of exceptions.
0.1.
The program affected and Program and associated application components (long runtime) options add information to the List of Selected Runtime Errors. The name of the program in which the dump occurred is shown. Just as importantly, the list displays the component (BC-CCM-MON, or FI-XXX-YYY or whatever) in which the dump occurred, if it can be found.
Sometimes the program and component may be misleading, if an application problem triggers a dump somewhere in infrastructure coding. But often, you can search for notes with the program and component. (The How to correct the error section in the dump long text shows a more extensive list of possible search terms.)
If you need to write an OSS message to SAP, you know the component in which to file the message.
If the component is not shown or you think that the component shown is misleading (the dump was finally triggered in infrastructure code), then you can find the component for an OSS message by following the path from the suspect program (for example, from the Active Calls/Events section) to the package of the program to the component. In SE80, go from the attributes of the program to the package. In the package, the component is displayed.
Surveying the Scene of the Disaster
You’ve set those useful dump list options. Now you want to get on with looking at that dump.
But once again – wait! Especially if you are working on an ill-defined problem – you don’t have a really good idea of what caused the dump – then it is wise to take a good look around the scene of the disaster before plunging into the details. Otherwise, you may miss vital clues to external factors that contributed to or even caused your dump.
Start your survey with the dump lists that ST22 offers, which offer useful information to the keen-eyed investigator.
The List of Selected Runtime Errors
The main dump display is the List of Selected Runtime Errors. Just click on Today on the ST22 start screen to take a look at current short dumps.
The list of may look something like the screen shot below. (This is from a system that is dumping quite busily – a headache for the QMs.)
As you look at the list of dumps, ask yourself these questions:
0.1. Is your dump a mass phenomenon?
0.2. When did the trouble with the dumps start?
0.3. Does the dump occur on only one server? Or for one user? Or for one program?
0.4. What other dumps occurred around the same time as your dump? Are there signs of system or database problems or problems in components which your program uses?
If your dump is a mass phenomenon, then you want to know this as quickly as possible If there are patterns in the list of short dumps, then you want to find these, because they could signal that your dump is part of some larger problem with the system or one of its components.
The Dump Overview
As you look at the List of Runtime Errors above, you may have the feeling that you can’t see the forest for the trees. There are so many dumps. They are clustered by type, but none of the sets of dumps seem likely to share causal explanations or to fit the journalistic questions posed above. What’s going on?
In cases like this, the more orderly view of dump traffic offered by the Overview function may help.
Choose Goto -> Overview from the ST22 start screen. Skip over the following selection screen with Execute. The system shows you what has been dumping in the system, sorted by dump category.
The foci of dump activity make it clearer what is going on in the system. First, the LOAD_PROGRAM_LOST short dumps tell us that we are in a development system, in which infrastructure source code (in this case) is being changed on the fly.
The UNCAUGHT_EXCEPTIONs and OBJECTS_OBJREF_NOT_ASSIGNED_NO may indicate that the developers have not cleanly implemented some programs as yet. Or perhaps some particular program or component is not working quite right. The scattering of dump activity among unrelated programs is in this case also explained by the fact that the system is apparently a development system. For a closer look, a double-click on one of the entries in the list selects the relevant short dumps for display.
The ABAP AS defines more than 1600 short dumps, all documented in loving detail by the kernel developers who are responsible for them. Some of these – the ‘usual suspects’ in the parlance of the film ‘Casablanca’ – already indicate to the savvy investigator that something other than an ABAP error is at play in the system. A list of the usual suspects might include these short dump IDs:
| Short Dump ID | Cause and Significance |
| SYSTEM_CORE_DUMPED | The operating system sent the work process a signal. Perhaps the computer was shut down or the process was explicitly killed, perhaps a serious OS error occurred.
No analysis or correction on the ABAP side is possible or necessary. The system core dump is prima facie evidence that other dumps occurring around the same time are related either directly or indirectly to the core dump. |
| DATASET_CANT_CLOSE
DATASET_CANT_OPEN DATASET_NOT_OPEN |
A file system error has occurred. Perhaps the file system is full, perhaps the file or directory did not exist.
Most likely a file system or configuration problem has caused the dump. Check the file system with ST06 or with OS tools. |
| INCL_NOT_ENOUGH_PAGING
INCL_NOT_ENOUGH_PXA INCL_NOT_ENOUGH_ROLL |
MEMORY_
In many cases, overuse of configured ABAP AS memory resources through one or more work processes has occurred, or the memory parameters in the instance profile are simply not adequately dimensioned for the size and workload of the instance.
The System Environment section of the dump shows you the memory consumption of the dumped program; you can check whether it in fact was the culprit (for example, it makes major use of Heap storage).
Also: Use SM50 to look for processes in PRIV mode. Use ST02 to check the ABAP buffers and memory. Use the Memory Analyzer in the new ABAP Debugger to check suspect programs.
DB_ERR_
| In many cases, a problem with the database (not necessarily provoked by misbehavior in an ABAP program) has occurred.
Use ST04 to check for database problems. |
|
| NI_HOST_TO_ADDR
NI_MY_HOSTNAME |
The system cannot identify a remote server by name or cannot even identify itself by name.
Somebody has messed up the network configuration or a network failure has occurred. Use network tools to analyze the problem. |
| TSV_TNEW_PAGE_ALLOC_FAILED | Usually due to a poorly implemented internal table. In some cases, however, may be due to inadequately dimensioned memory parameters in the instance profile.
If a problem with an internal table seems unlikely, then use ST02 to check the ABAP buffers and memory. |
One More Detour
You’ve looked at the dump lists. Perhaps you have taken a look at your dump as well. And you still aren’t sure what has gone wrong. One more detour – to the System Log – often provides additional useful clues before you finally get to the dump.
You need to know the application server on which the dump occurred, which you can get from the dump lists. Start the SysLog (transaction SM21) on the application server on which the dump occurred.
Find your dump in the system log. As a search term with CTRL-F, ‘short dump’ is useful. (Be aware that the system log writes on a circular file, so the report of your dump can be overwritten. Save the file if it is useful to you by downloading it.) Then look for events before – even well before – your dump and for significant events thereafter.
The Developer Traces
If even the System Log has not helped you to understand the dump, then you may need to look even further afield for more clues as to what went wrong. In this situation, the ABAP developer traces may help you to find the missing clues.
The developer trace is the log that each kernel component (work processes, message server, gateway, and so on) writes. Even in the standard setting, it offers a detailed trace of the activity of each kernel component, whereby in the case of an ABAP dump in most cases only the work process traces are useful. A work process dev-trace is written by each individual work process in an ABAP instance. To access the dev-trace, you therefore need both the name of the instance and also the number of the work process in which the dump occurred. Fortunately, the Selected List of Runtime Errors shows both items of information, in the Application Server and WP Index fields, respectively. is the work process number that you found in field WP Index. There is a current dev-trace file, which was started when the instance was started, as well as a dev_wThe dump you want is older than today? The ABAP AS regularly reorganizes dumps. By default, all dumps are deleted at the latest after seven days. But don’t give up. Enter the start and end dates in which you are interested in Own selection on the ST22 start screen. Often, especially if the system has not been dumping much, dumps up to a week old are still accessible.
If you need to hold on to a dump, be sure to lock it in the list of short dumps. It won’t be deleted during reorganization.
!https://weblogs.sdn.sap.com/weblogs/images/251686928/blog_st22_locked_dump.jpg|height=167|alt=Locking a Dump to Keep It Safe from Reorganization|width=555|src=https://weblogs.sdn.sap.com/weblogs/images/251686928/blog_st22_locked_dump.jpg|border=0!
New NetWeaver Information at SAP.com
Very Helpfull
