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_exception_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 SignificanceSYSTEM_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_</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.

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!</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 dumpsand aim this blog at any new SAP basis people looking for general basic informationon this topic. If your experienced with SAP and have many years dealing with this topiccontent then this is perhaps not for you but of course read on and enjoy anyway if youwant.

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

They are by no means "the top 5" ST22 dumps that will be reportedby 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 replyto 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 informationinto the selected dump reported.

Here is a selection of 5 common ST22 dumps encountered with a brief explaination and note. Do replyto this blog with your top ABAP dumps (maybe your top 5) and share your experiences how you investigatedfurther 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 anexhaustion 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 sizexMB 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 authorizedClient 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 pasteClick on the area and press CTRL+Y. It allows you to copy many lines at once and paste them afterwards.

Long messages on footerClick on the message and hold the mouse button. After moving the mouse to the left side.

Direct input logsThe transaction BMV0 (direct input logs) shows all direct input logs.

Graphics on SAPscriptThe program RSTXLDMC can be used to upload graphics (file extension .tif on PC files) into individual standard text.

Adding iconsCheck 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 quicklyStrike the key F4 (or click on matchcode symbol) and press ESCAPE. The current date is automatically set.

Setting up module FI/CO without using IMGAlmost all parameters can be set using the transactions ORFA (Asset Accounting), ORFB (Financial Accounting), and ORKS (Cost Center Accounting).

Displaying check object when not authorizedSoon after the lock try to access the transaction SU53. It reports the last objects verified and also the respective values.

Table analyses between two systemsThe contents of a table between two systems can be checked through the transaction OY19.

Correction and transport systemThe 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 systemThe 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 helpRun the command oerr ora �error number� under user ora�SysID�.

Oracle import and export explanationsRun 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 exitAfter 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 exitPoints 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.

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

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

SetValues 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 wordsIt 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 & formulasABAP/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 stuckIt happens mostly when archive area is overloaded. Run the program brarchive with deletion option to release disk space.

Short dumpNot 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 ignoredMake sure your SAP profile parameter contains the option abap/fieldexit = yes.

Transaction SE16 (table contents) does not work properlyMake 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 smallBefore increasing up the rollback segment size you should verify your programs. Very often the problem belongs to them.

Files for rollback segments are already enormousCheck 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 correctlyCheck 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 workAs 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 overloadedThe command tp clearold �SysID� cleans up the transport area according to parameters previously set on the plain file TPPARAM.

Instance does not establish communicationShutdown 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 = 1800The user connection is closed after 30 minutes without usage.

Login/fails_to_session_end = 3After 3 wrong password the connection is automaticly closed.

Login/fails_to_users_lock = 5After 5 wrong password the user is locked.

Login/min_password_lng = 6Password length at least 6 characters.

Login/password_expiration_time = 90Password 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_uploadTransfer files from the frontend to the application server.

Ws_downloadTransfer files from the application server to the frontend.

Ws_excelDownload files at the frontend in excel format.

Bp_joblog_readFetch job log executions.

Rs_send_mail_for_spoollistSend message from ABAP/4 program to SAPoffice.

Bp_event_raiseTrigger an event from ABAP/4 program.

So_wind_spool_listBrowse printer spool numbers according to user informed.

So_spool_readFetch printer spool according to the spool number informed.

G_set_get_all_valuesFetch values from a set.

Rzl_sleepHang the current application from 1 to 5 seconds.

Rzl_submitSubmit a remote report.

Ws_executeExecute an external program on the presentation server.

Ws_file_deleteDelete file at the frontend.

Ws_volume_getGet the label from a frontend device.

Ws_msgCreate a dialog box in which you display an one-line message.

Popup_to_display_textCreate a dialog box in which you display a two-line message.

Popup_to_confirm_stepCreate a dialog box in which you make a question whether the user wishes to perform the step.

Popup_to_confirm_with_messageCreate a dialog box in which you inform the user about a specific decision point during an action.

Popup_to_confirm_with_valueCreate 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_dataCreate a dialog box in which you make a question whether the user wishes to perform a processing step with loss of data.

Popup_to_decideCreate a dialog box in which you require the user between the two processing alternatives, or to cancel the action.

Popup_to_decide_with_messageCreate 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 serverThe 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 InputA 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 SystemIn an R/3 central system, both application and data base software are run on one computer.

ClientIn 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 SystemClient/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 ServerIt 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 codeThe 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 typeThe 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.

CorrectionIt contains all the objects that a developer has changed or created. It also controls customizing that has been maintained.

CSPA system to help SAP employees to give comprehensive support to their clients.

Data base serverThe 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 InputA recent technique to input data safely. It ensures application data integrity for background interfaces. See also batch input.

DispatcherThe system R/3 agent that identifies the type of task (on-line, update, batch, etc.) and sends the job to an idle work process.

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

EthernetIt 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 statusIndicator that specifies whether a field can take an entry in the entry screen or if it must be filled.

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

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

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

MatchcodeA tool for finding specific record. It is made up of search terms. It is used to find possible entries for an input field.

Number rangeA 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).

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

RepairIt contains all the objects that a developer has changed but the originals of the objects are located in another system.

RFCA way to implement communication between application programs via Abap/4 function call.

SemaphoresWhen a work process locks a resource, it sets a semaphore. Another work process that also wants to access it must then wait.

SysIDA 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/IPIt is the most widely used transport protocol for open systems. R/3 clients and servers communicate using TCP/IP.

TelnetIt provides terminal access to hosts using TCP/IP protocol. It is a well-known command among Systems Administrators.

Token RingIt 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.

TransportIt 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 processWork 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.

WorkbenchThe ABAP/4 Workbench, a graphical programming environment, is used to create application programs. The programming tools are accessed using buttons, dialogs and windows.

WorkflowIt consists of time and logical sequence of work items, which are processed by human agents or mechanical processing units.

X.25It is a standardized network access protocol for the packet switching network. The maximum transmission speed is 64 KBit/s.