Professional Documents
Culture Documents
ABAP Troubleshooting
ABAP Troubleshooting
Troubleshooting
Boris Gebhardt
Erik Sodtke
SAP AG
Warm Up
But the programming language ABAP and the surrounding tools will not let you
alone with the error.
But a major problem is to choose the appropriate tool at the right time
Syntax Check
Coverage
Analyzer
runtime checks
post mortem analysis
ABAP Debugger
Syntax Check
Runtime checks
Dumps
check environment
of the error
Performance
analysis
program flow
find statements
Screen
processing
ABAP dump
analysis (ST22)
Static checks
Coverage Analyzer
F1-help
tests of each category
/nslin
The result of an extended program check is a table which displays the messages
/ warnings / errors for each test family.
Errors and warning should be corrected by the developer. An error would be e.g.
to call a function which does not exist.
This will lead to a runtime error during program execution anyway.
From the overview table you get, via double click, to a detailed error description
and from here you can directly access the source code to do your correction.
Code inspector is
available with
WEB AS 6.10
for R/3 >=46C a transport
is available
-> note 543359
The code inspector (transaction SCI) is a mass test framework which is delivered
with WEB AS 6.10.
( for
From the ABAP editor you can access the code inspector with a default program
set (the program which is currently in use of the ABAP editor) and a default test
set. This global default test set has the name default and can be adapted to
your requirements like any other test set.
The default test set contains the following tests:
Performance checks (e.g. tuning of select statements)
Security checks (e.g. client depending INSERT/UPDATE.)
Extended program check
Example: searching for a special string (e.g. the use of a special SY field)
The result list contains all found occurrences, and all errors which occurred
during searching.
You can navigate from an occurrence to the relevant source line.
If a run didnt finish successfully, then you can restart the inspection from the
point where the error occurred.
(no rerun from scratch necessary)
10
11
The code inspector can be used to run the extended program check for all your
programs to get an overview of the current quality level.
12
Coverage Analyzer
The Coverage Analyzer is a tool for monitoring the system-wide
execution of ABAP programs.
You can
find program parts or complete programs which are never used and
may be obsolete.
find program parts that are executed very often and may benefit from
code optimisation
The Coverage Analyzer stores which programs and even modules of programs
where executed in a system and if any errors (dumps) occurred.
This allows you to ensure that all programs and even modules were covered by a
test.
13
Coverage Analyzer
SAP Easy Access
/nscov
The coverage analyser is divided in the administration and the display part.
The administration covers:
Switching on /off the data collection
You can specify the conditions, when a program shall get the flag tested.
e.g. at least 1 time executed without any error.
Reset the results for special programs to start a new test phase
Define test groups and attach users to these groups.
You can now display the results for these test groups.
Monitor the data collection to detect errors or problems (RFC connection )
Check the consistency and repair inconsistencies in the coverage analyser data. E.g between
shared memory and the database.
14
Global view:
Get the test coverage and number of errors for a development class or an author.
This is a good tool for a quality manager who has to ensure professional testing
and a good quality of a development project.
You see the statistics since the last reset and the accumulated values.
15
For a developer is is more important to see not only the test coverage of e.g. a
development class, but to go more into details and display the coverage of a
special program or even of one module.
In this example function group WBABAP was covered 76.1% by your test. If you
loot at the details, you see that e.g. the form BRANCH_TO_TYPE_ATTR hasnt
been executed and therefore is not tested (red traffic light).
16
Syntax Check
Extended Program Check(SLIN)
Code Inspector
runtime checks
post mortem analysis
ABAP Debugger
17
/h
SM37
My batch job crashed after 7 hours.
Which tool is a
good starting point?
ST22
The syslog is very helpful if you want to check the general situation of the system:
Which errors occur in the neighborhood of the real error? Which was the first
error of an error chain?
Additionally the syslog is a good starting point for a deeper analysis.
With the information about error kind/user/transaction/work process/ you can
tackle more detailed trace files like the developer traces.
(dev_w<n> files, accessible via transaction ST11)
18
Keep in mind:
The normal (local) system log only
shows log entries of the current
server !!
Update or batch errors may occur only on special
servers with update and batch work processes!
SAP AG 2003, TechED_Basel / ABAP257, Boris Gebhardt / 19
System messages are logged in a single circular file on a server. When this log
file reaches the maximum allowable size, the system starts overwriting the file
from the beginning.
Types:
If the R/3 system runs on UNIX hosts, there are two types of logs:
z Local: Each R/3 application server has a local log that contains messages generated by that server.
z Central: Each application server also copies its local log entries to a central log.
You can always use ALL remote logs to get the system log of all servers.
Accuracy:
Local log file: Always up to date
Central log file: There can be brief delays between when the system records a message in a
local log and when the same message is written to the central log
19
20
Get the date/time and user data from the system log and select the appropriate
dumps in transaction st22.
The following list contains the selected dumps.
Usually a periodic job deletes all dumps which are e.g. older than one week. To
ensure that a dump will not be deleted you can explicitly lock it. (-> compare note
11838)
21
Dump Analysis
At the end of this chapter you will be able to extract all the valuable info from a
short dump.
22
23
Some remarks on point 4). The other points are described in detail on the
following slides.
If you start transaction ST22 and select, e.g., all
CALL_FUNCTION_CONFLICT_LEN dumps of the last days, then you get a list
like this
Date
Time
Machine
User
FRANKM
FRANKM
FRANKM
Clt
X Error ID
000 C CALL_FUNCTI
000 C CALL_FUNCTI
000 C CALL_FUNCTI
Please check if all dumps occur on one machine or only one user is involved
24
Dump Analysis
25
Dump Analysis
26
Dump Analysis
main program.
Head of the program
group
current include
and source line
Use transaction SE38 with the Include name to access the source.
Knowing the number of the source line you can navigate directly to the faulty
statement.
There you can set a breakpoint for debugging or check the surrounding code.
Please be careful, sometimes the displayed source line is one statement behind
the faulty one.
27
Dump Analysis
Other programs
Function group
SAPLS_IMG_TOOL_5
current include
SAPLS_IMG_TOOL_5
LSVIMF59
External perform
current event
form VIM_BC_LANGU_ADD.
External perform
perform abc in program xyz.
endform.
28
Dump Analysis
For information about system fields, please use F1-help (in SE38) with ABAP System Fields
In our example we learn from the system fields that the program BGTEST5 looped 1000 times
until it failed. (sy-index = 1000).
In a LOOP AT ITAB loop sy-tabix would be essential.
If you have problems with memory consumption of large lists please have a look at sy-linno and
sy-colno (line number, column number).
The chosen variables display some variables in the neighborhood of the faulty statement.
The first line (blue) of the field contents displays the character representation of the underlying
hex-value. Please read the hex-values vertically.
In our case the interesting field P has the hex-value = 99 9C.
Since P is a packed number and not a character field, the first (blue) line of field P shows only
senseless characters. 99 9C is the hex-representation of the packed number 999.
With WEB AS 6.10 you get a variable list for each stack level!
We deal with a packed number with length 2. This means it can comprise only 3 digits.
Therefore we cannot exceed the number 999 and our program fails at the 1000th execution of the
incrementing statement.
With WEB AS kernel 6.20, there is a Chosen variables entry for every level of the ABAP call
stack.
29
Dump Analysis
event
program
include
The call stack shows you the flow of the program. With this information you can,
e.g., display (via transaction SE38) the include LCATREF20, line 655 in order to
check how the form CALL_DYNAMIC_FUNCTION_UNIT was called.
Please note that only the call stack, not a complete call history is available. If a
function is called and then the runtime returns from this function and goes on, you
will not find this function on the stack.
If you have, on the other hand, a CALL_FUNCTION_CONFLICT_TYPE, then the
called function is not on top of the stack because the call itself failed.
30
After terminating the internal session (/n) the environment of the dump is deleted
and you cannot access the debugger from ST22 any more.
31
Exercise 2:
If you run report ZTSTECHED02_ST22 you get the
DUMP TABLE_INVALID_INDEX.
(Remember the introducing story.)
Please do not debug the program.
Only analyzing the Dump text is allowed.
Find out why this DUMP occurred and how the program
should be corrected.
32
33
Syntax Check
Extended Program Check(SLIN)
Code Inspector
runtime checks
post mortem analysis
ABAP Debugger
34
35
Determine the specific bottleneck area of the program (ABAP vs. SQL)
Determine the SQL or ABAP statement causing the highest load
36
DB accesses:
Modul. units:
Internal tables:
File handling:
Others:
How is it measured?
During runtime analysis, the system measures the statements listed above.
The system stores these measurements in a performance data file. (DIR_ATRA)
You can evaluate the file (on the current server) immediately or at a later time.
The system subtracts the CPU consumption needed for doing the measurement
from the total CPU consumption.
ABAP Runtime Analysis trace file have the name AT<number> and are stored on
the local application server in the directory
specified in the profile parameter DIR_ATRA.
If ABAP Runtime Analysis has problems to read the filed and e.g. you get a
runtime error using Se30 before the first screen
comes up, then you may transfer (or delete) the AT trace files on this server to
another directory for later analysis.
37
38
With WEB AS 6.20 you can easily create a se30 variant with a new Create Icon.
This Button will substitute the Button temporary variant
With aggregation the hierarchy is not available.
For memory usage info in the hierarchy check the With memory use flag.
Program (parts) Particular units
This option allows you to switch on/off the ABAP trace during the running
transaction. Especially, if the you are only interested in a special part of the
transaction (e.g. between screen 3 and 4), then you should use Particular units.
Instruction for tracing Particular units: (trace program part between two screens)
Start SE30
Switch on Particular units for your variant
Start the tracing for your transaction. (Execution button)
The trace will be started as soon as you prompt /ron (Trace on) in your transaction. With /roff
the trace is stopped. (Or you use the menu: System -> Utilities -> Runtime Analysis -> Switch
On / Switch Off)
You can even use this technique in combination with the debugger. Set a
breakpoint at the beginning of the interesting program part and at the end.
If you stop at the first breakpoint, switch the trace on and at the second switch it
off.
39
Start the program / transaction via se30 with your variant. Step back to SE30 if
the interesting part of the transaction is finished.
You now see the new trace, which can be analysed.
If the trace file is not available, then please use the button Other file to
browse for your trace file.
If you got an error message when returning to SE30, which indicates that the
measurement failed,
then you may use the File info button to get the detailed error code.
If you used a variant with active aggregation the please rerun your trace with
Activation = NONE.
40
Call hierarchy
Access the hierarchy (only available with a no aggregation variant) from the
overview screen.
You get a list which represents the complete path through your application.
41
In the trace variant you specified already which statements and which parts of
your application shall be traced.
Additionally you can now filter which data you want to display.
Please notice that some display filters are switched on per default (e.g. no
system programs).
Therefore if you miss something, switch off all display filters and check your trace
variant.
You can step from the trace directly to the relevant source line.
42
Stack level
43
44
With Basis release >=46B you can use Runtime analysis to trace program which
run in a parallel session.
45
If you used a 46D kernel with patch level >=1413 (or 6.10 kernel patch level
>=427), then you can switch on the ABAP trace for idle processes as well (note
586940)
You must create your trace variant for the parallel trace as well.
(no aggregation to get the hierarchy)
Stop the trace after a short tracing time in order to avoid reaching the trace file
quota! (profile parameter abap/atrasizequota)
46
47
48
Strategy:
Restrict the trace file as much as possible (-> Variant).
Especially for long running programs.
Otherwise the file quota will be exceeded quickly.
Start with full or by call aggregation (only hit list available)
Restrict the statements e.g. only modules (functions, forms, methods)
Restrict the analysis in a second trace to the performance killing modules
Trace only a part of the transaction with the restriction Particular units
aggregation By call:
None:
no aggregation at all.
Profile parameter abap/atrasizequota and your variant settings limit the maximum
trace file size
49
Demo
50
Reliability of the execution times on machines running with more then one
processor:
The numbers represent not an exact measurement. But you get a good
impression which parts of the programs consume most of the time.
To get reliable results you should execute the measurement several times.
SAP AG 2003, TechED_Basel / ABAP257, Boris Gebhardt / 51
The overview of the runtime evaluation shows if the performance killer must be
searched in expensive selects (Database) or perhaps not perfect internal table
handling (ABAP).
For SELECTs a switch to the SQL trace (ST05) produces more detailed info
concerning tuning (which index was used ).
In our demo example the overwhelming part of the execution part is spent on
database operations.
51
Gross time
Time consumed in, e.g., a function. This includes the execution time of all modules
or other program parts which were traced and which were called from inside.
Net time
= Gross time minus traced program parts which were called inside.
E.g. the execution time of the FETCH T100 in FORM MSG_NR is subtracted from the gross time
to get the net time.
Sort the list by net time to identify the performance killer!
SAP AG 2003, TechED_Basel / ABAP257, Boris Gebhardt / 52
The hit list is sorted by net time: We get the most time consuming modules (here
forms).
FORM MSG_NR consumes ~ 39% of the total run time.
So this form seems to contain some expensive statements and
it seems to be worthwhile to go into details concerning this form.
Second run: We use the trace restriction variant
Program parts: only form MSG_NR
Statements: default
Duration / type: aggregation by call.
52
From the Fetch line we can directly navigate to the source line to check why this
SELECT is so time consuming.
In this case it is obvious. For counting DB entries the developer should use
aggregations like COUNT(*), but if it is not so easy, then a SQL trace (ST05) for
this
single statement would be the next step.
(missing index etc.)
53
Exercise 4b (optional)
Run the SE30 trace for the form NUMBER_OF_MESS
(program: ZTSTECHED02_SE30_PERF) as well.
(Switch on the internal-table statements in your restriction variant.)
Compare this with the trace of the same form NUMBER_OF_MESS in program
ZTSTECHED02_SE30_PERF_OPT.
Why is the performance of the LOOP in the optimized program so much better?
54
If you use no aggregation, you can choose within a variety of hit lists.
Most important is the DB hit list. Here you can see with one glance which DB
table are accessed how often and how much execution time is attached to them.
Additionally you get some info from the DDIC, concerning the Table type
(TRANSP, POOL, ) and the buffering.
The other hit lists provide info which internal table or class consumed most of
the time.
55
56
Screen Trace
Start screen trace via transaction: ST20
With SAP Basis release 46B, transaction ST20 (screen trace) is available to
analyse Batch Input or all other errors which are connected with screen handling
(field transport, screen sequence, resize, F1, F4 help)
In older releases you can use the report RSTRC000 to look at the screen trace.
(notes 0508748 or 0087150).
57
Trace level 2
Trace level 3
focus
OK-Code
data received flag
field contents
conversion exits
field exits
global fields
Load/generate dynpro
PBO,PAI,DCI,DCO steps
application/system modules
dark processing
main screen, subscreen
set screen, leave screen
call screen, skip screen
call dialog, call transaction
submit
step loop processing
messages
send/receive data from SAPGUI
58
set/get parameter
modify screen
batch input processing
screen resize
screen compression
subscreen tree
Syntax Check
Extended Program Check(SLIN)
Code Inspector
runtime checks
post mortem analysis
ABAP Debugger
59
60
For function modules use transaction SE37 -> Button Single Test.
In the generated function interface fill in the parameters and press Debugging
Please notice that this is the only possibility to debug functions which are
connected to Conversion Exits or Field Exits. They cant be debugged during the
running transaction (-> only isolated testing is possible)
If you debug a complicated transaction and you are sure that the problem occurs
in one function module, obtain the parameters for the function interface and try to
reproduce the error in an isolated test (SE37)
61
1
2
3
4
5
6
7
8
9
10
11
12
13
function z_debug_se37.
*"----------------------------*"*"Lokale Schnittstelle:
*"
IMPORTING
*"
VALUE(MY_IMPORT)
*"
EXPORTING
*"
VALUE(MY_EXPORT)
*"----------------------------my_export = 123.
write: / my_import.
endfunction.
If the type of the export parameter is not specified in the test environment of
SE37, a default field with type char(200) will be generated.
By the way, if you call this function from another program without specifying the
import parameter:
call function 'Z_DEBUG_SE37'
exporting
my_import = 'ABC'.
Then my_export in the function will have the default type char(4).
If you specify the parameter, the system will generate a field which has the same
type:
data int type i.
call function 'Z_DEBUG_SE37'
exporting
my_import = 'ABC'
importing
my_export = int
62
63
SM50:
Starting the debugger while the program is already running allows you to reach
the point of interest faster and more precisely.
Start the debugger (/h) in a transaction at the point where you have the problem
Start to debug e.g. a batch report when you think the problem comes up (e.g. high memory
consumption)
For debugging basis transactions usually the system debugging will be needed (/hs)
A batch job will not stop if a breakpoint is reached. Even for the statement
BREAK-POINT only a sys log entry (Breakpoint reached ) is generated.
But you can access the batch process via SM50 and then you can use all
features of the debugger
You can set dynamic/static breakpoints, display or change fields
To debug a batch job at a specific line of your code you may introduce an
endless loop in the code.
(I = 1. WHILE I=1. ENDWHILE)
Then you use sm50 to debug the batch process and change the condition to
leave the endless loop
64
If you have to analyze an aborted job, then you can restart the job in debug
mode.
This is a background simulation which actually runs in a dialog work process to
allow debugging.
But e.g. the spooling is done and sy-batch =X. So from the ABAP perspective
the program runs in a background environment.
Instructions:
Run SM37
Mark the job you want to restart in debug mode
Prompt jdbg in the ok code
You reached the debugger
65
Generate Shortcut
on the desktop
66
This technique is really helpful if you are on a popup and want to start debugging.
You cant access the OK-field, therefore the shortcut technique is the only
possible solution to debug the ABAP of a popup directly.
Please assure (especially if you use a CITRIX client) that you have the
(Windows) permission to save files on the desktop!
67
Increase program
section size
Step to current
statement
Scroll source code
Control buttons
F8
F7
F6
F5
Return
Execute
Single Step
Execute:
Return:
Continue:
watchpoint,
68
Show next
list line
69
The call stack shows the current call hierarchy (which program was called by
which program)
It is always possible to switch to the other levels of the hierarchy. Within this level
it is possible to access all variables and their values, but you have to keep in
mind that only the local variables have their current values; global variables might
have been changed during the program flow.
The switching itself is triggered by double-clicking on the desired level.
Please keep always in mind that you only see the pure call hierarchy. If the
program jumped to another routine and returned you are not able to find a trace
in the call stack.
(For this purpose use ABAP Trace [SE30].)
If system debugging mode is off, you will not be able to switch into system
modules!
(switch on system debugging: /hs)
70
(3)
Doubleclick
SAP AG 2003, TechED_Basel / ABAP257, Boris Gebhardt / 71
In the fields view you can switch to hexadecimal display by using the magnifier
icon (1).
Starting from the fields view you can double-click on any field name; this will lead
into the detailed field view (3) or, if the field name specifies a structured field, you
will be switched into the structured field view (2).
A double click onto any field in the structured field view or table view will lead you
into the detailed view of the simple field.(3)
You can also access the field directly:
Enter: sflight-paymentsum.
You can access the different views also from the menu:
Goto -> Display data object ->
zSingle field
(Ctrl + F2)
zStructured field
(Ctrl + F3)
zInternal table
(Ctrl + F4)
71
(1)
Doubleclick
(2)
Doubleclick
SAP AG 2003, TechED_Basel / ABAP257, Boris Gebhardt / 72
Starting from the fields view you can double-click onto the field name to branch
into the table view (1).
A double click onto any field in the table view will lead you into the detailed view
of the field. (Like shown in the slide above, into an internal table (3))
You can also access the field directly:
Enter: my_struc-itab2[].
([] means table contents / itab2 might be only the header line of the table)
Example:
my_struc-itab2[2]-mandt will display the field mandt of the second line of the
internal table my_struc-itab2.
If you have an internal table with a header line:
Data: itab like sflight occurs 0 with header line.
Then itab represents the header line and itab[] the body of the table.
72
(2) change
(1) edit
If you enter a variable name in the variable area of the debugger, you will be able
to see the contents of the variable (and scroll if needed). When using structures
or tables instead of normal variables the system will display the work area of the
variable. Entering a variable can also be done by double-clicking on a variable in
the coding.
It is also possible to change the contents of a variable by overtyping the contents
and pressing the pencil. This change will be documented in the SYSLOG and you
need a special authority. (S_DEVELOP/DEBUG/01)
Its not possible to change the hex-values of fields.
If you allow a user to change variables via the debugger, then this user can
overcome almost all authority checks.
73
Columns
In order to manipulate internal tables you can either use the button Table or
double-click on the internal table. The system will switch to the table view screen.
Within this view you can:
scroll horizontally and vertically through the table
hide columns by deleting the column title in the column line
shift column by entering a specific column name instead of a displayed column name
(e.g. replace VONTG by PERDLY and you will see PERDLY as first column)
This is merely a display functionality. Your changes have no effect on the internal table.
search (R/3 Release > 4.0B) through the lines by using the search button in the application
toolbar. Positioning the cursor on a certain line uses the line contents as search pattern.
The normal search button (in the standard toolbar) searches in the source code.
insert, modify, delete an entry
z Please keep in mind that the entry is only changed column by column (except with the delete button)
z If you want to insert a line, you need to click on insert first and to change every column of the row afterwards.
z If you want to change a whole row, you need to do that column by column as well
74
75
Doubleclick
You can display all attributes of your ABAP objects. To see the private/protected
attributes use the filter icon.
If you display a reference, you get the referenced instance name
nr<class_name> (e.g. 69<CL_GUI_ALV_GRID>).
Double-click on the instance displays the content of this instance.
With Goto -> System -> Find references you can display all references that point
to a special instance of a class!
76
The button event for an instance displays all events of this class and the attached
event handler.
77
78
79
80
Counter
In the view Breakpoints you can
The breakpoint overview allows you to delete, e.g., only the dynamic breakpoints
at WRITE.
So you dont have to delete all breakpoints. You can decide very specifically
which breakpoints should be deleted.
Example (Counter):
You are in a form which fills an internal table. This form is called very often.
During runtime a dump occurs at an INSERT statement, which complains about a
too big an internal table and a lack of memory.
Now you have the problem to debug the program.
You place a breakpoint at the proper INSERT statement, but unfortunately the
INSERT statement is executed thousands of times.
Now you can use the Count-technique.
Set the count-field to, e.g., 1000 and execute. If you get the dump, decrease the
value to 500, then 250, With this technique you can quickly detect the exact
moment when the error occurs and start debugging there.
81
Debugger: Watchpoints
If you set a watchpoint on the field matnr (matnr = '1234'),
the debugger stops as soon as matnr contains the value
'1234'.
If you do not specify a condition, the debugger stops as soon as
the field matnr changes.
Program flow
Matnr = 0000
Matnr = 0120
Matnr = 1234
82
create watchpoints
specify the logical operator between the watchpoints to stop
either when all specified conditions are true or at least one of
them
Create
change or delete
watchpoints
If you wish to stop the program depending on the contents of a variable, you have
to use a watchpoint.
Within the watchpoint you can specify the relational condition under which the
system should stop (<, >, <>, <=. >=). Even the comparison with another variable
(rather than a given value) is possible
If you create more than one watchpoint, you can link them together with AND or
OR.
Local and global watchpoints:
The debugger always looks at the memory address of the watchpoint-field.
Some special variables and fields are shared between programs.
(e.g TABLES, COMMON PART, SY-fields)
This means two program look at the same memory address.
If you use local watchpoints, the debugger checks not only if the contents of the
memory address has changed, but compares also the actual program with the
watchpoint-program.
If you use global watchpoints, the debugger will always stop if the memory
contents change, independent of the program.
83
Debugger: Exercise
Run transaction SE09:
Where does the pre-set USER = GEBHARDT come from?
1.
2.
(TRDYSE01CM-USERNAME)
3.
4.
84
Demo
Demo
itab-*sys*
itab[]
itab[]+0(128)
*itab[] (header is only filled when table is not initial!)
Debugger: Settings
Menu: Settings ->
Display and change all
86
SE38/Attributes /Display
System debugging can be switched on via menu Settings or by /hs in the OKcode field.
If you debug a CALL FUNCTION statement, but the runtime skips the function,
check if this function is part of a function group with status S (System program).
This effect can be eliminated by System Debugging
System Debugging is necessary if you want to debug:
variants
selection screens
logical databases
the update process
batch processing
With Release < 4.5A the system modules are not visible in the call stack if you
use normal debugging.
87
Dialog WP
COMMIT WORK.
FUNCTION ABC .
...
Update WP
Field 1
UPDATE
ZDEBARFC.
...
VBDATA
VBMOD
ENDFUNCTION.
SAP AG 2003, TechED_Basel / ABAP257, Boris Gebhardt / 88
If you use the normal direct update then after each screen the DB -changes are
committed.
To ensure that you can ROLLBACK all DB changes of a multiple screen
transaction you must use the SAP LUW concept. This means usually you use
CALL FUNCTION... IN UPDATE TASK .
If you call a function in Update task then this function is not called instantly but
merely its name and the interface data is stored in database tables(VBMOD
/VBDATA)
If a COMMIT WORK is reached then the stored function modules which are
linked to this LUW will be read from the database and executed in a free update
workprozess.
88
COMMIT WORK
If you use the normal asynchrony update then after a Commit Work the update
work will be done by another workprocess (update workprocess). Therefore the
debugger cant debug
the update procedure and will stop after the COMMIT WORK.
If you switch on Update Debugging then after the COMMIT WORK the update is
executed in YOUR process and therefore the debugging can go on.
Please keep in mind that many customer bundle there update work processes on
one server.
This implies that the process switch after COMMIT WORK can include a server
switch as well.
If the program uses SET UPDATE TASK LOCAL then the update is executed in
the same process and the update data is not stored on the database but in the
memory. In this case you dont need update debugging.
89
Transaction SM58
Position your cursor on the
function module.
Then choose Edit -> Debug LUW
SAP AG 2003, TechED_Basel / ABAP257, Boris Gebhardt / 90
If you locked a background function in the debugger, you will find this function
after the COMMIT WORK in transaction SM58.
If you use the normal asynchronous update, after a COMMIT WORK the update
work will be performed by another work process (update work process).
Therefore the debugger cant debug the update procedure and will stop after the
COMMIT WORK.
If you switch on Update debugging, after the COMMIT WORK the update is
executed in YOUR process and therefore the debugging can go on.
If you have to deal with aborted updates, then you can analyze them in
transaction SM13. There you can restart, test or even debug the
failed update modules.
90
91
If you are able to debug the memory consuming program, you can use the ITABTOP25 system area to find the biggest internal table.
The columns alloc. Netto and Used netto differ because we always allocate a
certain amount, then use this up for e.g. several appends, and then we allocate
fresh memory.
92
With Release > 4.6D it is possible to display a ranked list of the most important
memory consumers.
This includes all loaded programs and all possible data types. (Internal tables,
ABAP Objects, )
This feature allows us to see with a glance which fields hold most of the memory.
With WEB AS 6.40 the memory inspector is delivered. This is a tool which is
integrated in the debugger and provides a standalone framework to compare and
analyze memory snapshots. This functionality will be available in the WEB AS
6.20 at the end of the year.
(note 606368)
93
94
Questions?
Q&A
95
Feedback
Thank You !
The SAP TechEd 03 Basel Team
96
No part of this publication may be reproduced or transmitted in any form or for any purpose without the express
permission of SAP AG. The information contained herein may be changed without prior notice.
Some software products marketed by SAP AG and its distributors contain proprietary software components of other
software vendors.
Microsoft, WINDOWS, NT, EXCEL, Word, PowerPoint and SQL Server are registered trademarks of
Microsoft Corporation.
IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390,
OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, Informix
and Informix Dynamic ServerTM are trademarks of IBM Corporation in USA and/or other countries.
UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.
Citrix, the Citrix logo, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, MultiWin and
other Citrix product names referenced herein are trademarks of Citrix Systems, Inc.
HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C, World Wide Web Consortium,
Massachusetts Institute of Technology.
JAVASCRIPT is a registered trademark of Sun Microsystems, Inc., used under license for technology invented
and implemented by Netscape.
MarketSet and Enterprise Buyer are jointly owned trademarks of SAP AG and Commerce One.
SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver and other SAP products and services mentioned
herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in
several other countries all over the world. All other product and service names mentioned are the trademarks of
their respective companies.
97