ABAP Runtime Error ST22 Transaction using Short Dump Analysis

http://www.kodyaz.com/sap-abap/abap-runtime-error-st22-short-dump-analysis.aspx

For displaying ABAP short dumps in SAP systems, ABAP developers can use SAP transaction code
ST22. It is also possible to reach ST22 ABAP Runtime Error screen following the menu path:

SAP Menu > Tools > ABAP Workbench > Test > Dump Analysis

As seen in the following screenshot, the current numbers of ABAP short dumps occured today and
yesterday are displayed. ABAP developers can easily list the short-dumps using the Today and Yesterday
butons on the screen. Of course, for more detailed searches ABAP workers can use the filter screen with
different search parameters.

Analyzing Problems Using ABAP Short Dumps: Part I

Posted by Stephen Pfeiffer in stephen.pfeiffer on Nov 11, 2009 6:57:25 AM

inShare

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.

!https://weblogs.sdn.sap.com/weblogs/images/251686928/blog_st22_exception_chain_scaled.jpg|height=
326|alt=image|width=700|src=https://weblogs.sdn.sap.com/weblogs/images/251686928/blog_st22_except
ion_chain_scaled.jpg|border=0!

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

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.
SYSTEM_CORE_DUMPED

No analysis or correction on the ABAP side is possible or necessary.


DATASET_CANT_CLOSE
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.
A file system error has occurred. Perhaps the file system is full,
perhaps the file or directory did not exist.

DATASET_CANT_OPEN

DATASET_NOT_OPEN 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_</p></td><td width="284" valign="top"><p>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. <br /><br />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). <br /><br />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.</p></td></tr><tr><td width="284"
valign="top"><p>DB_ERR_<DBS>

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.

The system cannot identify a remote server by
name or cannot even identify itself by name.

NI_HOST_TO_ADDR

NI_MY_HOSTNAME Somebody has messed up the network

configuration or a network failure has
occurred. Use network tools to analyze the
problem.
Usually due to a poorly implemented internal
TSV_TNEW_PAGE_ALLOC_FAILED
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|al
t=Locking a Dump to Keep It Safe from
Reorganization|width=555|src=https://weblogs.sdn.sap.com/weblogs/images/251686928/blog_st22_lo
cked_dump.jpg|border=0!</body>

Analyzing Problems Using ABAP Short Dumps: Part II

The first part of this weblog did not quite manage to open a short dump as of Release NW04s 7.0 EHP1
for display. Instead it reviewed ways to extract contextual information from the short dump lists and
elsewhere.

In this second part of the web log we, in the words of W. C. Fields, grab the bull by the tail and face the
issue. In a short dump, you want to answer these primary questions:

 What exactly happened?

 Where did it happen?
 How can the problem be corrected?

We will look at the diagnostic information and aids that the short dump offers for answering these
questions.

From the Top: The Context of the Error

You have finally made it into one of the ABAP short dumps. You'll see a display that looks quite similar
to this one.
Maybe the Short text , What happened, Error Analysis, and Source Code Extract will be enough to let you
diagnose and correct the problem. That's often the case when a dump was caused by a relatively stupid
programming error. But let's take it from the top and see what diagnostic help the short dump offers, just
in case.

The Short Dump Heading

On a bold red background at the top of every dump you will find the short dump ID and the date and time
at which the dump occurred. Together with the Application Server and the WP Index from the dump list,
you have all the information that you need to look for relevant messages in the ABAP System Log or
Developer's Trace (see Part I of this weblog).

If an exception occurred and the runtime error was cacheable, the exception that caused the dump is also
shown.

Together with the program name (ZSP_COMPLETE_FQDNS) from What happened?, you also already
have enough information to search for a relevant OSS note. The combination of dump ID or exception
name and program name should find the right note, if it exists. You'll also find a more extensive list of
search terms for the OSS in the How to correct the error section in the dump.

The System Environment: Context Information and Where Did That RFC Actually Come From?

You probably skip over the context information presented under System Environment. But there are some
worthwhile nuggets of information in there.

If you plan to search for OSS notes and messages, then you will need the system release and SP levels,
kernel patch level, and other facts on the ‘scene of the crime' to see whether notes or messages fit your
problem. If you plan to open an OSS message for SAP, then you can simply save and attach the entire
short dump. (From the dump display in ST22, choose System -> List -> Save -> Local file.) That should
help Support to respond quickly to the problem.

If you are analyzing the problem yourself, then here are three important bits of information:

 At the bottom of the System environment list, you'll find a compact overview of the memory
usage of the program at the time that it dumped. If you see that the program has allocated heap
memory, then check to see in section Information on where terminated to see if the program
was started in a background job. If the program was not running as a background job, then you
might want to take a look at the memory consumption of the program in the Debugger with the
Memory Analyzer or with the ABAP Runtime Analysis (transaction SAT). A dialog program - one
running interactively in a dialog process - gets heap memory - private, process-local memory -
only if the memory resources of the Web AS have been exhausted. (Just to confuse things,
 background jobs manage memory differently, and get heap memory before getting ABAP
Extended Memory.) If you see a dialog program with heap memory, then something is wrong
with the program. Or the memory resources configured in the Web AS are inadequate. Or
possibly other processes are memory hogs and have forced this process into heap memory.
 Check the User and Transaction section to see if the dump occurred while processing a dynpro
screen. The User and Transaction list specifies the screen and ‘Screen Line' at which the dump
occurred. Screen Line is actually the line in the flow logic of the dynpro at which the faulty
module was called. You'll also get this information out of the Source Code Extract as well, but
here, you won't have to piece together the information on which module in which dynpro in
which program failed.
 If you are dealing with an RFC problem in the RFC server, then the Server-Side Connection
Information tells you where the RFC call came from. You can then find the short dump on the
caller side, which may help you to understand the server-side dump.

And of course, the opposite is true. From a dump on the client side of an RFC interaction, you can find
out where the call went.

What Happened Exactly: Short Text, What Happened, Error Analysis

The key question is: what happened exactly? You need to understand the problem in detail to be able to
correct it. For this understanding, the Short text, What happened, and Error analysis sections are
invaluable.

The Short text states what happened in a single line. In our

MOVE_TO_LIT_NOTALLOWED_NODATA dump (above), the short text is this:
Interesting - so I'm trying to overwrite a constant in my program?

The What happened section of this dump adds the name of the program in which the error occurred.

In the screen shot above, the identification of the faulty program is quite simple, since I was too lazy to
write a faulty method that perhaps resided in a separate include. But you may see more complicated
explanations of the location of the error like this:

 The termination occurred in the ABAP program "SAPLSVIM" in "VIM_BC_LANGU_ADD". The

main program was SAPLS_IMG_TOOL_5. The termination occurred in line 330 of the source code
of program LSVIMF59. In this case, SAPLSVIM is the current program, in which the dump
occurred, and the SAPL prefix indicates that we are actually talking about the function group
SVIM. VIM_BC_LANGU_ADD is the processing block (function module, method, form routine) in
which the dump occurred. LSVIMF59 is the name of the include in which VIM_BC_LANGU_ADD
is located.
 Or, if the crash occurred in a class, you might see something like this: The current ABAP program
"CL_IM_SPROXY_BADI_CTS=========CP" had to be terminated because ...,
where CL_IM_SPROXY_BADI_CTS=========CP is the name of the class pool in which the dump
occurred. You can enter the full name in SE80 or SE24 to display the class, but more commonly,
you would simply enter CL_IM_SPROXY_BADI_CTS...

In many short dumps with few possible causes, the What happened section describes the error that
occurred quite exactly. The MOVE_TO_LIT_NOTALLOWED_NODATA dump, however, can arise out
of many different circumstances. It's not possible to say which transgression in the code produced the
short dump, so detailed explanations are forced from What happened into the next very useful section, the
Error Analysis.

Short dump texts are written by SAP kernel developers. The Error analysis sections often provide really
detailed information about the possible causes of a short dump, which in turn reflects the detailed
knowledge of the kernel that these developers have. There is often a lot of text, but the time taken to read
it through will be rewarded.
For example, we learned from the short text that my program dumped because it tried to overwrite a
constant. I don't see any constant in the bad code below. I just wanted to complete the fully-qualified
domain names of a list of hosts. Do you see the error in the code?

If you don't see where I try to overwrite a read-only field, then see the seventh point in the discussion in
Error analysis, the one that begins "Accesses using field symbols..." Experience has shown that a lot of
people just skip over the explanations in What happened and Error analysis. This may end up costing
them more time than it saves.
Where Did It Happen: Source Code Extract

The SAP Short Dump developers were right to put Source Code Extract in initial caps, because, if you are
lucky, this is a really nice, helpful section of the dump. You're shown exactly where the program was
aborted. A few people don't know that from here, you can jump right into source code in the ABAP
Editor with a double-click. In the dump that we have been following, it would be possible in the editor to
branch to the definition of the internal table LT_CSMNSDIC, where you might notice that the
CDNSNAME field has been declared as part of the key of the sorted internal table...

If you can reproduce the problem, then you can set a breakpoint right from the short dump in order to stop
just before the short dump occurs. You can then use all of the tools of the new ABAP debugger to
investigate the cause of the dump.

If the code line shown by the pointer doesn't seem to make any sense in the context of the dump, then take
a look at the previous line of code. Occasionally, the instruction counter may still advance even after a
dump has been triggered, so that the >>>>>> pointer points at the line following the bad line of code.

Where Did It Happen: Active Calls/Events

In program failures that involve infrastructure like Web Dynpro, or calls between components, or in
which an uncaught exception has been passed up through the callers, the Active Calls/Events section may
help you to understand the components involved in the crash. This call stack is a useful supplement to the
point of failure marked in the Source Code Extract, because in the stack you can see how you got to the
point of failure.

You read the Active Calls/Events list from the bottom up. It shows all of the report events, dynpro
modules, functions, methods and form routines through which the path of execution has come. You can
jump into the ABAP Editor at any level in the call stack. This means that you can set breakpoints all
along the way to the dump if you think that a problem at a higher level resulted in the dump at the end of
the stack.

There are two things to remember about the ABAP call stack:

 It's a call stack and not a complete history of calls. If the flow of execution returns from the last
callee in the stack, that return from the callee is not shown in the stack. If the short dump
occurs in the caller, then you might wonder why the stack shows a different program as the end
point of execution than the What happened section.
 If ABAP dumped because of an incompatible call to a function module or method
(CALL_FUNCTION_CONFLICT_GEN_TYP, CALL_FUNCTION_CONFLICT_LENG,
CALL_METHOD_CONFLICT_TYPE, ...), then the called function or method will not appear as the
last level in the call stack. The call itself failed, so the callee is not shown in the stack.
Where Did It Happen: The Hard Way

Usually, the Source Code Extract shows where your error occurred. But if you are unlucky, you may
have to determine this vital piece of information the hard way. As a not so tragic example, if a short dump
occurs in a macro, then the source code pointer will be set to the macro call, not to the statement in the
macro that caused the problem.

An error in the kernel may leave no information in the Source Code Extract at all.

In cases like these, how can you find out where the short dump occurred?

Let's start with the no-source-code-its-a-macro case. The Source Code Extract does show where the
misbehaving macro was called. Since you can jump into the ABAP Editor and then forward-navigate into
the macro with a couple of clicks, you can first see if a good look at the macro code might reveal the
problem.

If you still can't see where in the source code the problem occurred, then the ABAP Control Blocks
(CONT) section may help you to localize the problem. The CONT table shows the CCBs - Control-
Control-Blocks - which represent the ABAP statements to be executed in the processing blocks of an
ABAP program. The short dump contains an extract of the CONT table showing the CCBs that lead up to
the dump and the next few statements that were to be processed. Read the list of CCBs from the top
down.

Low-level as it is, the CONT does not care whether statements are in a macro or not - and it shows the
short dump pointer that you know from the Source Code Extract. Unfortunately, a double-click on the
CCB at the dump pointer still takes you only to point in the source code at which the bad macro was
called. But the halfway intelligible CCB names may be enough to show you at which line of code in the
macro the problem occurred.

First of all, if the macro is not too long, then clicking on the CCBs to jump into the ABAP Editor shows
you where the macro started. Then, with a little jumping back and forth between the CONT table and the
ABAP Editor, you can start to equate the CCBs and the statements in the faulty code.

In our case, the SQLS and PAR1 CCBs turn out to reference an SQL SELECT well before the macro call.
CCB 68, BRAF, represents the start of an IF control structure in which the macro is called. The COND
and PAR1 CCBs depict the macro statement that actually failed: CONCATENATE &1 ‘.sap.corp' into
&1.
In the case I-have-only-a-kernel-dump (SYSTEM_CORE_DUMPED, ABAP_ASSERT, etc.), the
Source Code Extract section will really be empty. In this case, the dump section Active Calls in SAP
Kernel provides clues as to the location of the error. But since no customer or ABAP application
developer should have to read a kernel stack, we mention this only for the record. If you have a short
dump that originated in the kernel and it is not simply because somebody pulled the plug on the ABAP
AS, then all you need to do is provide the short dump with the Active Calls in SAP Kernel section to SAP
Support.

Other situations with no where-it-happened location: Should you not have any luck in finding out
exactly where the program went down the tubes, then a useful tip is to try to reproduce the problem in
transaction SAT, the ABAP Runtime Analysis. In SAT, you can trace the execution of an ABAP program
at the level of ABAP processing blocks. Run your program to its dump (provided that this does not take
too long - a non-aggregated SAT trace can get large quickly). Then check the SAT trace. It may help
you find out pretty exactly where to look for the problem, even if the dump occurred in a macro.

Also, you can use ST05, the Performance Analysis, to switch on (in a controlled fashion - for your user,
for example) a detailed trace of program activity. Be aware that the trace will also include the writing of
the short dump. The dump processing starts where you find activity on DB table SNAP, so search for the
problem area before that point.

See help.sap.com for help with using SAT and ST05.

The Third Major Question: What's the Solution?

Naturally, the discussion that you will find in the How to correct the error section of a short dump tends
to be a bit generic. Developers are constantly finding new and inventive ways to repeat old errors, like
the MOVE_TO_LIT_NOTALLOWED_NODATA error that we have been examining. It's therefore not
possible for How to correct the error to describe exactly what you should do to fix a dumping program.

Even so, the combination of the discussion in How to correct the error and taking a good look at the
faulty code often leads to success in correcting the problem. In the case of the
MOVE_TO_LIT_NOTALLOWED_WA dump that we have been examining, the dump astutely remarks
that ‘The field to be overwritten is a parameter or a field symbol.' If you were not aware that the sort keys
of a sorted table may not be overwritten in a field symbol, then the tip that a field symbol may be
involved might help you get onto the right analytical track.

In the end, however, understanding and correcting the cause of a short dump rests on your shoulders. You
will have to extract as much information from the short dump as possible, and use this information to
illuminate what went wrong in the code.

Gathering More Information

A short dump addresses more or less directly the journalistic questions of what went wrong where and
what to do. Should these questions be addressed ‘less' rather than ‘more' in a dump, then it is good to
know that a dump also includes a lot of additional supporting information that can help you in your
analysis.

System Variables

As an ABAP program executes, it is accompanied by an entire swarm of system variables, like Jupiter
with its cloud of little moons. Some of these variables are well-known, like SY-SUBRC, the return code
set by many ABAP instructions or SY-TABIX, the counter in LOOP AT and READ TABLE internal
table instructions.

When a short dump occurs, ABAP preserves the state of the system variables at the time of the
crash. You can see the contents of these variables in the Contents of system fields section. Here are some
of the system variables that are most likely to be useful:

 SY-SUBRC usually shows the last return code setting before the program crashed. A non-zero
SY-SUBRC from a method or function preceding an instruction that dumped may illuminate for
you what went wrong.
 SY-TABIX. In a short dump raised from within a LOOP AT table or after a READ TABLE instruction,
SY-TABIX tells you what record from the internal table was being processed when the program
failed.
 SY-INDEX provides the same iteration-count information for DO and WHILE loops.
 SY-LINNO (number of lines in an ABAP list) and SY-COLNO (number of columns in an ABAP list)
show how much memory a large ABAP list consumes, if you are having memory problems with a
large list.
 SY-MSGID and SY-MSGNO, if set, let you look up the last message issued by the failed program
in transaction SE91. SY-MSGV1 - 4 show any message variables that previously were set (not
necessarily for use in the most recent message).
 SY-DATUM and SY-UZEIT may show a more accurate and earlier time stamp for the initial
program abort than the date and time associated with the short dump itself. If you are sifting
through the System Log or Developer Traces (see the Part I of this weblog), then the few
 seconds difference that you may see can be important in establishing to chronology of events in
a failure.

Program Variables

For the Chosen variables section, the short dump infrastructure takes a quick run through the collapsing
program context grabbing any program and infrastructure variables it finds that are currently in
scope. The situation is a bit like the belated shopper running through a grocery just at closing time -
there's no guarantee that the shopper will bring home everything that he or she was supposed to
buy. Even though the dump infrastructure may not capture everything, much more often than not you
will find the variables and values that you want to see.

Since SAP_BASIS Release 6.20, the short dump infrastructure has captured a separate set of Chosen
variables for each level in the Active Events/Calls ABAP call stack.

If you are analyzing a data-related problem, then a careful look at the Chosen variables may clarify the
problem. In one recent example, an OSS message reported a short dump because ABAP could not convert
the character value 229812 to an integer (dump ID CONVT_NO_NUMBER). Since this is one of
ABAP's easiest tricks, the dump is at first glance pretty mystifying. A quick look at the character field in
Chosen variables showed, however, that the character field held not ‘229812' but rather ‘229812##믆䀾
##蠤䋒##p###'. The fact that the field was either not correctly initialized or was filled with non-character
data explains the conversion failure, at the very least.

Chosen variables shows the size (here, one record with a length of 3440 bytes) of an internal table, as
well as useful information such as the type of organization of the table (here, a sorted table). The table
display can be useful in analyzing the popular dump of type TSV_TNEW_PAGE_ALLOC_FAILED (no
more memory available for an internal table), since you can see how much memory has been allocated to
hold the rows of each internal table. (The amount of storage allocated for the rows may not, however, be
the amount of storage used by the rows of the table. If, for example, a table holds only data references to
objects, then storage for references may not be all the memory actually consumed by the table and its
contents. The references are relatively short. The objects may occupy much larger amounts of memory.)

In an upcoming release, the table display will contain at least the start of the contents of each of the first
five records of each internal table that is captured.

Finally, object references that have not been initialized (a favorite cause of
OBJECTS_OBJREF_NOT_ASSIGNED_NO, and others...) are easy to pick out in Chosen
variables. Just use Ctrl - F to search for ‘:initial}'.

Note that a random mouse click in the Chosen variables display switches the display from the relatively
attractive formatted view to an unformatted view. Don't be alarmed. Just click on F3 / Back to return to
the formatted display.
An Ounce of Prevention...

Is worth a pound of cure, as the old saying goes.

Don't forget that ABAP offers logging and checkpoints that can be activated when needed (see
help.sap.com). With these, you can turn on switchable logging, breakpoints, and assertions to help you
with diagnosis and trouble-shooting, should something go wrong in your program after it has reached
your users.

And don't forget the suite of tools that the ABAP Workbench offers to help you find errors before your
users do, starting with tools for static checking like the Code Inspector (Transaction SCI), continuing with
the ABAP Unit Test facility, with which you can even go so far as to practice test-driver
development. The best ABAP short dump is the one that you never have to analyze.

- This weblog is based in part on Boris Gebhardt's Advanced ABAP Workshop: ABAP Analysis Tools.
You can find more information on ABAP Test and Analysis Tools at help.sap.com and also in ABAP:
Advanced Tools and Techniques, Volume 2, SAP Press 2009, ISBN 978-3-8362-1151-2.

Your top 5 ABAP Dumps are ?

SAP basis administrators and system administrators working with SAP will
have experience with the system generating ABAP dumps in ST22 transaction
(various reasons).

In this blog I would like to share some experiences with some common ST22 dumps
and aim this blog at any new SAP basis people looking for general basic information
on this topic. If your experienced with SAP and have many years dealing with this topic
content then this is perhaps not for you but of course read on and enjoy anyway if you
want.

Before we cover some initial basics for our new readers I will explain why I titled this
blog 'Your top 5 ABAP Dumps are ?'. In this blog 5 commonly reported blogs that are generally
encountered will be included.

They are by no means "the top 5" ST22 dumps that will be reported
by an SAP system as these obviously would change from system to system but perhaps you have
cataloged your top 5 and would like to share them. Please feel free to add comment and reply
to this blog with your findings.

Some background for the new reader on this topic.

In order to list the ABAP runtime errors that have occurred you must log on to the affected ABAP
system.

Next thing to do is to run the ABAP Dump Analysis using the transaction code ST22.

On the this screen you have the options to define the selection criteria that is searched for the whole list of
stored runtime errors.

It is also possible to call the most current runtime errors: by clicking on the 'Today' button in the Standard
selection group box, the system displays a list of runtime errors for the current day in reverse i.e. the
newest files first.

Then a list will appear of all of the runtime errors relevant to the selection criteria.

You can sort the list according to various criteria.

Ok, so everyone can now check on their system for any ABAP dumps and drill down for more
information
into the selected dump reported.

Here is a selection of 5 common ST22 dumps encountered with a brief explaination and note. Do reply
to this blog with your top ABAP dumps (maybe your top 5) and share your experiences how you
investigated
further and the impact they have on your daily administration tasks.

Some common ST22 dumps:

____________________________

1)

SYSTEM_CORE_DUMPED

In most situations SYSTEM_CORE_DUMPED is related to the R/3 system kernel. As generally advised
and in keeping with best practice upgrade to the latest available kernel patch to solve the issue (see note
SAP 19466).

Detailed analysis of the coredump at the Kernel will provide more reasons behind the dump.

2)

TSV_TNEW_PAGE_ALLOC_FAILED

In brief the ST22 DUMP 'TSV_TNEW_PAGE_ALLOC_FAILED' simply indicates an

exhaustion of available SAP memory resources by a process.
When this DUMP is reported more memory was requested by the SAP system because the program
needed to expand an internal table. The memory resource was not vailable. When the available Extended
Memory is exhausted the process will enter PRIV mode (seen in SM50) and will start to use Heap
Memory (local memory). This will happen in this order in Windows or vice versa in Unix. A process in
PRIV mode locks out any other user to use the corresponding work process. If there is enough memory
for the process to finish no error is reported.

3)

SYSTEM_NO_TASK_STORAGE

SYSTEM_NO_TASK_STORAGE dumps are also address space/memory related.

The advised steps to take in relation to this dump is to refer to SAP notes 110172, 552209, 546361 for
further details. This dump in general relates to 32-bit address space limitation regarding memory
resources. On 32-bit platforms the long term solution is to use 64bit (regarding MS Windows see SAP
note 996600).

Another possible cause for the dump SYSTEM_NO_TASK_STORAGE is running an old SAP collector.
SAP do recommend to run with the latest available collector.

4)

CALL_FUNCTION_SINGLE_LOGIN_REJ

This dump is generally reported when there are insufficient authorization to login to the trusted system.
4 different error codes are related to CALL_FUNCTION_SINGLE_LOGIN_REJ

0 - Incorrect logon data for valid security ID.

1 - Calling system is not a Trusted Systemor security ID is invalid.

2 - Either user does not have RFC authorization (authorization object S_RFCACL), or a logon was
performed using one of the protected users DDIC or SAP*.

3 - Time stamp of the logon data is invalid.

Refer the below SAP notes about CALL_FUNCTION_SINGLE_LOGIN_REJ dump:

986707 - No authorization to log on as a trusted system (RC=1)

128447 - Trusted/Trusting Systems
204039 - Authorization check in trusted system

5)

PXA_NO_SHARED_MEMORY
In most situations where the ST22 DUMP PXA_NO_SHARED_MEMORY occurs there is not enough
contiguous address space to create the buffer of size
xMB Approx (where x is size in mega bytes).

The SAP note 129813 may be relevant as some DLLs may be positioned that are stopping the creation of
this large buffer on Windows platforms.

Also SAP note 307976 gives information about this dump type PXA_NO_SHARED_MEMORY.

__________________________

If your common findings in ST22 are not listed above please do add comment with your frequent
observations and share your experiences on this topic.

Do you find the actual ST22 dump empowers you to find and resolve the root cause of the dump? Again,
share your experience here with other users.

You do not have to be an "ABAPer" in order to resolve ABAP dump issues. The common way to deal with
them is to look up in ST22. Here you can see a descrition of what happened. You can further look up OSS
notes for the Error code, or for any programs, table or FM mentioned in the dump.

Dumps happen when an ABAP program that is running in a background generally causes an immediate
termination of the background job.

ABAP short dumps are something which trouble any SAP user (sometimes help the user to understand
the system needs better). We normally do a search for SAP notes or contact SAP to solve these dumps.
But hardly takes any chance to understand the meaning of the dumps. Here I am listing some 'famous'
ABAP dumps and trying to explain what are they. Please note that the solutions provided here may
different from case to case. These should be used just as a 'first aid'.

1) STORAGE_PARAMETERS_WRONG_SET

The problems with the dump STORAGE_PARAMETERS_WRONG_SET are mainly related to the general
restrictions of the 32bit OS. You can address up to 4GB of virtual memory. Each process in OS is running
in its own context and can address max. 4GB. The parameters which are related to ‘heap memory' ie
abap/heap_area_dia, abap/heap_area_nondia, abap/heap_area_total are should be set to 2 GB.
Common approaches which we can take for this dump are:
a) Please use in the 'boot.ini' file the switch '/3GB' and restart your whole computer as described in the
below SAP Notes:
SAP Note 552209 - Maximum memory utilization for processes on NT/Win 2000
SAP Note 313347 - Windows NT, 2000, 2003: Editions and memory usage.
b) Another way to avoid this problem is to try to add more criteria to your report/program/transaction
so that there will be fewer entries that need to be retrieved from your database or buffers. This way, the
system would not need to use up much resource to complete the transaction. The query may have been
quite big already and the load cannot be accommodated. So please do add more criteria or options so
that there will less data to fetch.
c) To decrease the value of the parameters: rdisp/ROLL_SHM, rdisp/PG_SHM
d) Migrate to 64-bit OS (as per SAP Note 931024 and SAP Note 996600)

2) TSV_TNEW_PAGE_ALLOC_FAILED

The error TSV_NEW_PAGE_ALLOC_FAILED means that more memory was requested by the system
because the program needed to expand an internal table, but not is available. When Extended Memory
is completely used up, the process will go into PRIV mode and it will starts using Heap Memory in case of
Windows or vice versa in case of Unix. Once this enters into PRIV mode, no other user will be able to use
the corresponding work process. If there is enough memory for it to finish, you will not see the error.
Please refer the following SAP notes:
SAP Note 649327 - Analysis of memory consumption.
SAP Note 20527 - Runtime error TSV_TNEW_PAGE_ALLOC_FAILED
SAP Note 185185 - Application: Analysis of memory bottlenecks
SAP Note 369726 - TSV_TNEW_PAGE_ALLOC_FAILED

3) TSV_TNEW_OCCURS_NO_ROLL_MEMORY

The dump TSV_TNEW_BLOCKS_NO_ROLL_MEMORY usually means that the roll buffer has been
exhausted. Please check the usage of your roll buffer with ST02->History->Page. Near the bottom of the
screen you can see ROLL BUFFER history. If the roll buffer has been exhausted, you can increase the size
with parameter rdisp/ROLL_MAXFS, but make sure you have sufficient disk space to handle the
additional size of this buffer if it writes to disk.
Please refer the following SAP note:
SAP Note 185185 - Application: Analysis of memory bottlenecks

4) LOAD_PROGRAM_LOST

The LOAD_PROGRAM_LOST error can occur when there are two or more versions of a given program
loaded into the buffer at any given time. This happens when the program is changed by one user while it
is still in use by another user. When a user gets to the program that is having this problem and R/3
attempts to load the generated version from the buffer, it sees that the version is not the most current
and tries to swap it out for the most current, but the load was lost from the PXA buffer, hence it throws
the dump of LOAD_PROGRAM_LOST. LOAD_PROGRAM_LOST are the result of the combination of not
enough PXA space + changes of programs which are in use currently. A running program can't run with
two different versions of one program. Ask the users restart their transactions (/nST22). By the way, if
the PXA would be big enough then the user who does not leave their transaction for weeks will not see
the changes to this application until they restart the transaction.
Other way to correct the error is you need to run transaction SAMT & regenerate the program(s) that
are listed in the dump. You can then do a $SYNC in the command field in the affected application server,
but make sure that the other application servers are not running at that time. After the $SYNC, the other
app servers can be brought up and the buffers should then be in sync.
Please refer the following SAP notes:
SAP Note 5451 - LOAD_PROGRAM_LOST
SAP Note 24824 - Inconsistencies in a Program Load
SAP Note 10367 - Termination LOAD_PROGRAM_LOST
5) CALL_FUNCTION_SIGNON_INCOMPL

The short dump CALL_FUNCTION_SIGNON_INCOMPL is typical of an RFC-Call with incorrect or missing

logon-data. So, we have to find out where the call is coming from.
Please refer the following SAP notes:
SAP Note 171805 - Determining RFC client when sign-on problems occur.
SAP Note 684788 - Possible reason for CALL_FUNCTION_SIGNON_INCOMPL.
SAP Note 901256 - Rabax "CALL_FUNCTION_SIGNON_INCOMPL".

6) RFC_NO_AUTHORITY

This error mostly appears with the user SAPSYS. The user SAPSYS is an internal user, it is not a personally
used ID in the R/3 system. However, all system errors and ABAP programs are run via this user id. As per
note 93254, since release 4.0 the parameter auth/rfc_authority_check is set on 1 per default. This
means, as long as you did not set it explicitly to value ‘0', any incoming RFC call is checked as described
in the mentioned note.
The common approaches which we can take on this dump are:
1. Deactivate RFC authority Check: set auth/rfc_authority_check to value '0' (zero) in your profile and
restart the server. (This is the least secure option as any authorization checks are disabled for all RFC
requests).
2. Assign full RFC authorities to the users who need to connect to your system via RFC.
Please also check the user id provided in RFC connection (check from SM59) which cause the dump
RFC_NO_AUTHORITY. Make sure that this user has sufficient authorizations.
Please refer the following SAP notes:
SAP Note 171805 - Determining RFC client when sign-on problems
SAP Note 93254 - RFC short dump RFC_NO_AUTHORITY
SAP Note 91980 - Missing output of RFC short dump after login errors

7) SYSTEM_NO_TASK_STORAGE

For this error, please go to service market to download the latest patch for your SAP Application release
and apply the patch. The latest patch would be useful for the problem. The
SYSTEM_NO_TASK_STORAGE is a known problem and related to limitation of 32bit OS. Please see notes
110172, 552209, 546361 for details. As long term solution you have to use 64bit Windows (Note
996600).The cause for the dump SYSTEM_NO_TASK_STORAGE could also be an old sap collector. SAP
recommends using the updated collector version always.
The common approaches which we can take on this dump are:
1. Check your settings match the recommendations mentioned in SAP Note 146289.
2. Are ulimits set according to SAP Note 323816? (Referenced in SAP Note 146289)
3. If there is no additional instances on same host then it should be possible to increase
EM/TOTAL_SIZE_MB from 4096 MB towards the RAM and even higher so that ztta/roll_extension can be
reached. Also the swap space should be set according to SAP Note 153641 for this.
Please refer the following SAP notes:
SAP note 789477 - Large extended memory on AIX (64-bit) as of Kernel
SAP note 191801 - AIX 64-bit with a lot of Extended Memory
SAP note 445533 - Lots of extended memory on AIX (64-bit)
SAP note 581319 - Signal 33 on AIX (64-bit only)
SAP note 153641 - Swap space requirement for R/3 64-bit kernel
8) CALL_FUNCTION_NOT_FOUND

The error CALL_FUNCTION_NOT_FOUND is due to the fact that the program called the function which
doesn't exist in the library. Means the requested function module is not found in table TFDIR. Also you
may get this error if the buffered version of the TFDIR contains errors. The error needs to attention
based on the function module. You may take a general approach mentioned in the SAP Note 98458.
Please refer the following SAP note:
SAP Note 98458 - SAPMSSY1, CALL_FUNCTION_NOT_FOUND

9) CALL_FUNCTION_SINGLE_LOGIN_REJ

This error usually comes when you don't have sufficient authorization to login to the trusted system.
This dump accompanies with 4 different error codes:
0 - Incorrect logon data for valid security ID.
1 - Calling system is not a Trusted System or security ID is invalid.
2 - Either user does not have RFC authorization (authorization object S_RFCACL), or a logon was
performed using one of the protected users DDIC or SAP*.
3 - Time stamp of the logon data is invalid.
Please refer the following SAP notes:
Note 986707 - No authorization to log on as a trusted system (RC=1)
SAP Note 128447 - Trusted/Trusting Systems
SAP Note 204039 - Authorization check in trusted system

10) SYSTEM_CORE_DUMPED

Generally, SYSTEM_CORE_DUMPED is related to R/3 system kernel. Upgrade the kernel patch to the
latest may solve the issue. But without a detail analysis of the coredump at the Kernel, we cannot
conclude the reason behind the dump. I would recommend contacting SAP for this dump.
SAP Note 19466 - Downloading SAP kernel patches

mySAP Tips & Tricks

 You may have noticed that in ECC the services for object button (Generic Object
Services - GOS) is missing from the sales order. This can be useful to find related
IDOCS but was taken off in 4.7 due to performance reasons. If you set user
profile/parameter SD_SWU_ACTIVE to X by going to SYSTEM-USERPRFOLE-
OWNDATA the button will be available to you again.

SAP R/3 Tips & Tricks

 Logging on without being authorized

Client 066 usually exists in a SAP system due to EarlyWatch services. Often this client
 does not have master users. If it is true, anyone can log into the system using the client
066, user SAP*, and password PASS. Enjoy yourself.
 Special copy and paste
Click on the area and press CTRL+Y. It allows you to copy many lines at once and paste
them afterwards.
 Long messages on footer
Click on the message and hold the mouse button. After moving the mouse to the left
side.
 Direct input logs
The transaction BMV0 (direct input logs) shows all direct input logs.
 Graphics on SAPscript
The program RSTXLDMC can be used to upload graphics (file extension .tif on PC files)
into individual standard text.
 Adding icons
Check the icon code using transaction ICON. A technical view can be found at the
include named �ICON�. Sequences of characters begin and finish with the symbol @.
Even plain files under operating system can contain those strings.
 Filling up an empty date field quickly
Strike the key F4 (or click on matchcode symbol) and press ESCAPE. The current date
is automatically set.
 Setting up module FI/CO without using IMG
Almost all parameters can be set using the transactions ORFA (Asset Accounting),
ORFB (Financial Accounting), and ORKS (Cost Center Accounting).
 Displaying check object when not authorized
Soon after the lock try to access the transaction SU53. It reports the last objects verified
and also the respective values.
 Table analyses between two systems
The contents of a table between two systems can be checked through the transaction
OY19.
 Correction and transport system
The transaction SE10 provides the easiest way to manage any request/transport and
corrections.
 General command field formats

/n Skip to the next record if you are processing one batch input session
/bend Cancel a batch input foreground process
/nend Close all R/3 sessions and logoff
/nxxxx Call the transaction xxxx in the same session
/o Generate a session list
/oxxxx Call the transaction xxxx in an additional session
/i Delete the current session
/h Turn the debug mode on
/$tab Reset all buffers (for System Administrators)
/$sync Synchronize instances buffers (for System Administrators)


 Report command field formats

%pri Print the current report

%pc Download the current report
 %sc Call the find function
p+ Go to the next page
p- Go to the previous page
p++ Go to the last page
p-- Go to the first page


 Helpful reports

RSCLTCOP Copy tables across clients

RSAVGL00 Table adjustment across clients
RSINCL00 Extended program list
RSBDCSUB Release batch-input sessions automatically
RSTXSCRP Transport SAPscript files across systems
RSORAREL Get the Oracle Release
RGUGBR00 Substitution/Validation utility
RSPARAM Display all instance parameters
RSUSR003 Check the passwords of users SAP* and DDIC in all clients
RSUSR006 List users last login


 Unconditional mode when importing or exporting a request/transport
Run the command R3trans -u under user �SysID�adm.
 Main return codes of tp program

0 Successfully done
4 Warnings occurred
8 Errors occurred
12 Fatal errors occurred
16 Internal errors occurred


 Scheduling of system maintenance jobs

RSBTCDEL Clean the old background job records

RSDBCREO Clean batch input session log
RSPO0041 Removing old spooling objects
RSSNAPDL Clean the old ABAP error dumps


 Locking the whole system
Using the command tp locksys �SysID� only the user SAP* will be allowed to login.
The command tp unlocksys �SysID� cancels the lock.
 Connection between SAP R/3 and operating system
The command sapevt can be used to trigger an event from the operation system. Thus,
a job previously defined within R/3 will be released.
 SQL code help
Run the command oerr ora �error number� under user ora�SysID�.
  Oracle import and export explanations
Run the command imp help=yes under user ora�SysID�. This format can also be used
with exp, impst, and expst.

SAP R/3 Hints TOP

Of course it does not guarantee a successful implementation. It is a great deal of summed up

aid, though.

 Team integration has to be enhanced

 Set high standards of performance for implementation team
 IT teams and users have to work closely during the implementation
 New ways of thinking and acting must not be discarded
 Do not underestimate the user training needs
 Project management should be on the critical list
 The nearest SAP branch should be your partner
 Consultants are not always the key to succeed
 Consultants are a good source of knowledge. On the other hand, letting them make
configuration changes the transfer of knowledge will be harmed
 Foreign consultants usually do not know country-specific details
 Deepening your basis knowledge is always useful
 Avoid changing standard R/3 objects as much as possible
 Always follow the SAP rules to give names to your own objects
 Establish SAP connection as soon as possible
 Exchange information with other companies
 Focus on interfaces with non-R/3 applications
 Plan the whole environment carefully (servers, network, protocols, etc.)
 Development and production environment should be totally independent

SAP R/3 Enhancements TOP

Some special features allow you wide modifications without changing standard SAP R/3
objects. Those techniques are not as widespread as they should be. In fact they are powerful
tools.

 Field exit
After entering a value in a field, it can be checked through a field exit. The system makes
the field value available to be checked and changed in an ABAP/4 function.
 User exit
Points previously set in the system that let you evaluate data. The fields available are
also previously defined by SAP. All fields value available can be checked in an ABAP/4
program.
 Validation
It allows solid data entry regarding special rules. According to previous rules, the system
can evaluate an entry and a message can appear on the user's terminal if a check
statement is not met. A validation step contains prerequisite statement and check
statement. Both of them are defined using Boolean Logic or calling an ABAP/4 form.
  Substitution
Fields contents can be changed using substitution. When data are being entered, the
data can be substituted by another value regarding rules previously defined. A
substitution step contains prerequisite statement, substitution value and substitution exit.
All of them are defined using Boolean Logic or calling an ABAP/4 form.
 Set
Values or ranges of values are specified under a set name. Sets are easier to create and
maintain instead of using tables. They give you more flexibility when maintaining your
system.
 Key words
It allows changes on field description according to data element. The short key word
used on most screen to identify the corresponding field contents can be changed too.
 Requirements & formulas
ABAP/4 forms that can be used to handle pricing procedures, rounding rules, copy and
data transport Sales activities.

SAP R/3 Troubleshooting TOP

 System gets stuck

It happens mostly when archive area is overloaded. Run the program brarchive with
deletion option to release disk space.
 Short dump
Not always the problem is technical. Try to create all SAPoffice users through
transaction SO32 (create all SAPoffice users) and review your application data carefully.
 Field exits are completely ignored
Make sure your SAP profile parameter contains the option abap/fieldexit = yes.
 Transaction SE16 (table contents) does not work properly
Make usage of the menu option to regenerate the display program. You can also try
changing key words according to field names. Choose Option -> Parameters users.
 Rollback segments are too small
Before increasing up the rollback segment size you should verify your programs. Very
often the problem belongs to them.
 Files for rollback segments are already enormous
Check the rollback segments configuration. It has to match the allocated area on
tablespaces. Changes have to be done using Oracle tools.
 Extended help under windows does not link correctly
Check the file sapdoccd.ini under your presentation server. It must be present in the
main windows directory and should assign to help files directory.
 Release procedure with classification does not work
As a matter of fact you are not the only one to notice it. It hardly works. Before using
release strategy you should apply all notes on OSS. Pray might be useful too.
 Transport area is overloaded
The command tp clearold �SysID� cleans up the transport area according to
parameters previously set on the plain file TPPARAM.
 Instance does not establish communication
Shutdown the whole system and check the Interprocess Communication Facilities. Any
references should be found. Either the command IPCS (UNIX) or showipc �INSTANCE
NUMBER� (SAP) show all message queue, semaphore set and shared memory
 identifier. Before trying again you have to remove them using the command IPCRM
(UNIX) or cleanipc �INSTANCE NUMBER� (SAP).

Note: Research based on version 3.0f under Unix, Oracle data base and Windows.

SAP R/3 Security TOP

Simple changes can rise your system security. Usage of SAProuter is a good choice when
correctly implemented. Login through SAP LogonPad (from version 3.0f onwards) improve the
access control. SAP profile parameters shall also contain:

 Rdisp/gui_auto_logout = 1800
The user connection is closed after 30 minutes without usage.
 Login/fails_to_session_end = 3
After 3 wrong password the connection is automaticly closed.
 Login/fails_to_users_lock = 5
After 5 wrong password the user is locked.
 Login/min_password_lng = 6
Password length at least 6 characters.
 Login/password_expiration_time = 90
Password expires after 3 months.

Note: I do not have to waste my time telling you to change all default passwords.
Make sure to have the master user SAP* in all clients otherwise anyone can
log into your system. See Tips & Tricks.

SAP R/3 Programming TOP

Indeed these powerful ABAP/4 functions are very interesting and can bring some advantages.
Improve your home development easily. They belong to standard objects and should never be
changed.

 Ws_upload
Transfer files from the frontend to the application server.
 Ws_download
Transfer files from the application server to the frontend.
 Ws_excel
Download files at the frontend in excel format.
 Bp_joblog_read
Fetch job log executions.
 Rs_send_mail_for_spoollist
Send message from ABAP/4 program to SAPoffice.
  Bp_event_raise
Trigger an event from ABAP/4 program.
 So_wind_spool_list
Browse printer spool numbers according to user informed.
 So_spool_read
Fetch printer spool according to the spool number informed.
 G_set_get_all_values
Fetch values from a set.
 Rzl_sleep
Hang the current application from 1 to 5 seconds.
 Rzl_submit
Submit a remote report.
 Ws_execute
Execute an external program on the presentation server.
 Ws_file_delete
Delete file at the frontend.
 Ws_volume_get
Get the label from a frontend device.
 Ws_msg
Create a dialog box in which you display an one-line message.
 Popup_to_display_text
Create a dialog box in which you display a two-line message.
 Popup_to_confirm_step
Create a dialog box in which you make a question whether the user wishes to perform
the step.
 Popup_to_confirm_with_message
Create a dialog box in which you inform the user about a specific decision point during
an action.
 Popup_to_confirm_with_value
Create a dialog box in which you make a question whether the user wishes to perform a
processing step with a particular object.
 Popup_to_confirm_loss_of_data
Create a dialog box in which you make a question whether the user wishes to perform a
processing step with loss of data.
 Popup_to_decide
Create a dialog box in which you require the user between the two processing
alternatives, or to cancel the action.
 Popup_to_decide_with_message
Create a dialog box in which you inform the user about a specific decision point via a
diagnosis text.
 Business Objects

SAP R/3 Glossary TOP

Information Technology has many key words and SAP R/3 has introduced many others. In order
to understand even better this field you should keep in mind those terms.
 ALE (Application Link Enabling)
It provides integration for separate R/3 systems, keeping full interaction. This makes
possible distributed enterprise applications.
 Application server
The application server is used to run the business application programs in the R/3
client/server concept. The application modules are loaded from the data base server to
the application server as required. Thus the application server requires only storage
capacity to accommodate UNIX, Swapping and the SAP runtime environment.
 Batch Input
A technique to input data safely. It ensures application data integrity for background
interfaces. It pretends to be someone typing. See also direct input.
 CATT (Computer Aided Test Tool)
It allows you to combine and automate sequences of repeatable transactions in test
procedures. CATT reduces the number of manual tests, and forces you to test
systematically, defining input values and expected test results.
 CCMS (Computer Center Management System)
It allows you to monitor, control and configure your R/3 system. This toolset lets you
analyze and distribute client workloads and report on resource consumption for system
components.
 Central System
In an R/3 central system, both application and data base software are run on one
computer.
 Client
In commercial, organizational and technical terms, a self-contained unit in an R/3 system
with separate master records and its owns set of tables.
 Client/Server System
Client/server systems are structured modularly, with components working in a
sender/receiver relationship. Software components can also be used in a client/server
relationship.
 Communication Server
It provides the connection between local area and wide area networks and may be either
a router, a bridge or a gateway. In R/3 installations, the communication server must
support the TCP/IP protocol over wide area networks.
 Company code
The smallest organizational unit for which a complete self-contained set of accounts can
be drawn up for purposes of external reporting. This involves recording all relevant
transactions and generating all supporting documents for legally-required financial
statements, such as balance sheets and profit and loss statements.
 Computer type
The R/3 system supports various computer types of SAP's platform partners, such as
Bull, DEC, IBM and HP. The suitability of a particular computer type depends on
sufficient CPU performance.
 CPI-C (Common Programming Interface-Communications)
Common Programming Interface of Communication has been introduced by IBM as a
high-level interface to SNA/LU6-2. CPI-C has become the subject of the X/Open
standardization and is used by SAP to facilitate program-to-program communication
between R/3 and external system. SAP offers CPI-C libraries based on TCP/IP.
 Correction
It contains all the objects that a developer has changed or created. It also controls
customizing that has been maintained.
 CSP
A system to help SAP employees to give comprehensive support to their clients.
 Data base server
The data base server stores the SAP application programs and data in the R/3
client/server concept. It also handles the SAP update program and batch jobs.
 Direct Input
A recent technique to input data safely. It ensures application data integrity for
background interfaces. See also batch input.
 Dispatcher
The system R/3 agent that identifies the type of task (on-line, update, batch, etc.) and
sends the job to an idle work process.
 EarlyWatch
It is a service that entails having your R/3 installation regularly inspected by SAP
employees, in other to ensure high system availability and high data throughput at all
time.
 Ethernet
It is a LAN architecture using bus topology. The transmission speed is 10 MBit/s.
 FDDI (Fiber Distributed Data Interchange)
It is a local high-speed network with ring topology based on light wave conductors. The
transmission speed is 100 MBit/s.
 Field status
Indicator that specifies whether a field can take an entry in the entry screen or if it must
be filled.
 Firewall
It is a means of controlling access through a public network to a private network.
 FTP (File Transfer Protocol)
It is the most commonly used file transmission protocol of the TCP/IP protocol family.
 GUI (Graphic User Interface)
A graphical interface used by SAP environment as part of the three tiers. It is normally
called user front-end.
 IDES (International Demonstration and Education System)
It is a model of an international firm. It is a separate demonstration and education
system for speeding up the pilot process.
 IMG (Implementation Management Guide)
It is a hierarchical structure that reflects the R/3 component hierarchy and contains every
configuration activity. Released from version 3.0 onwards.
 Instance
It means application server and each one has its own set of work processes.
 IDoc (Intermediate Document)
An IDoc is a data container for data exchange between SAP systems or between an
SAP system and an external system.
 ITS (Internet Transaction Server)
It links the R/3 application server with one or more Web servers, thus enabling the R/3 to
communicate with the Internet.
 Kernel
It means a standard core previously configured. A set of default parameters delivered
with the system.
 LAN (Local Area Network)
It is a network foa a tightly limited area with high level data transmission performance.
Common LANs include Ethernet, Token Ring and FDDI. These LANs support different
transport protocols, such as TCP/IP and IPX.
 Matchcode
A tool for finding specific record. It is made up of search terms. It is used to find possible
entries for an input field.
 Number range
A range of numbers that are laid down per file for the assignment of document numbers.
It can be internal (carried out automatically by the system) or external (carried out
manually by the user).
 OLE
It is a technique introduced by Microsoft to incorporate objects of one application into
another.
 OSS (Online Service System)
SAP's Online Service System offers fast and effective help for R/3 System problems. It is
also the basic element of communications between customers, partners, and SAP.
 Repair
It contains all the objects that a developer has changed but the originals of the objects
are located in another system.
 RFC
A way to implement communication between application programs via Abap/4 function
call.
 Semaphores
When a work process locks a resource, it sets a semaphore. Another work process that
also wants to access it must then wait.
 SysID
A set of three letters or number that identify a system. Some sets are not allowed
because they are used by SAP. They are informed when the system is installed.
 TCP/IP
It is the most widely used transport protocol for open systems. R/3 clients and servers
communicate using TCP/IP.
 Telnet
It provides terminal access to hosts using TCP/IP protocol. It is a well-known command
among Systems Administrators.
 Token Ring
It is a LAN architecture with ring topology. The transmission speed is 4 MBit/s or 16
MBit/s. This involves a 'free token' which circles the loop picking up transmissions. The
receiver station places a confirmation bit into the busy token. As soon as the busy token
reaches the sender station again, it is converted back to a free token and sent on to the
next station.
 Transport
It is a request to transport objects from the software development environment, identified
as the source system, to the specified target system.
 WAN (Wide Area Networks)
They are normally operated either by the telephone company or by private companies
that offer leased lines, switched lines or packet lines.
 Work process
Work processes perform the bulk of the processing carried out by SAP systems. They
perform dialog steps in user transactions and carry out updates, lock management,
printing services, and so on.
 Workbench
The ABAP/4 Workbench, a graphical programming environment, is used to create
application programs. The programming tools are accessed using buttons, dialogs and
windows.
 Workflow
It consists of time and logical sequence of work items, which are processed by human
agents or mechanical processing units.
 X.25
It is a standardized network access protocol for the packet switching network. The
maximum transmission speed is 64 KBit/s.