-
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
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!
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 SysIDadm. 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 oraSysID.
-
Oracle import and export explanations
Run the command imp help=yes under user oraSysID. 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.