Analyse Problem - Using ABAP

Debugger
Debugger Fundamentals

Active Global Support

March 2009

1
Course Content (current Highlighted)

Introduction Dump Analysis

R/3 Basis Technological Overview ABAP Trace (Runtime Analysis)

Debugger I Performance Trace

Screens Memory Management

ABAP Messages Batch Processing

Debugger II Updates

Dynpro Trace User Exits

Syslog

2
Unit Objectives

This unit will prepare you to perform the following tasks:

Start ABAP programs in debugging mode
Use SE38 and SE37 for debugging purposes
Debugging of running batches
Debugging of popups
Use basic debugger feature like breakpoints and watchpoints

3
 Debugger

I have no idea how to use debug

techniques like dynamic breakpoints
Why do I need these techniques ?

This chapter is designed to give a basic introduction into the debugger and will set the
focus on the handling.

4
Debugger 1 - Customer Problem

I create a customer via FD01.

I get an annoying popup and then FD01 ends
without saving my customer.
My colleague has no problems and only the
customer Kohl is faulty

5
Debugger 1 - Customer Problem - Solution

(1)Switch on debugging
on the odd popup
(use the shortcut)
(2) get the calling function
---> USER EXIT !!!!!
(3) Set a breakpoint on this
function
(4) Analyze the code or debug it

6
 Start an ABAP Report With the Debugger

SE38
Button ‚Debugging‘

The report will be started directly in debugging mode.

If you insert /h in the ok-code field then you will not debug RSPARAM but the editor
(SE38).

7
 Start an ABAP Function Module With the
Debugger
SE37
Button ‚Single Test‘

Fill in the parameters for the

function interface and press
Debugging

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 can‘t 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 then get the parameters for the function interface and try to reproduce the
error in an isolated test (SE37)

8
 SE37 - Demo

1 function z debug se37.

Function module Z_DEBUG_SE37 2 *"-----------------------------
3 *"*"Lokale Schnittstelle:
4 *" IMPORTING
SE37 5 *" VALUE(MY IMPORT)
Button ‚Single Test‘ 6 *" EXPORTING
7 *" VALUE(MY EXPORT)
8 *"-----------------------------
9
10 my_export = 123.
11 write: / my_import.
12 endfunction.
13

Where is the output ??

My_export should be 123 ??

If the type of the export parameter is not specified in the test environment of SE37 then this
tool will generate a default field with type char(200).

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

my_export will have the type i in the function module.

9
 Start a Transaction With the Debugger

Transaction: SE93
-> Fill in your transaction (e.g. VA01)
-> Menu path: Transaction Code -> Test -> Debugging

The transaction will be started directly in debugging mode, starting with the first PBO
module of the first screen.

Alternative: Starting debugging of transaction from SE80 (Object Navigator)

SE80 Button ‘Other Object’ (Shift F5)
Fill Transaction (e.g. VA01)
Press return
Menu path: Transaction Code -> Test -> Debugging

10
 Start Debugging of an Already
Running ABAP Program

For a transaction: For a batch job or long running program

SM50:
OK Code-Field in the transaction:
/h (switch on debugging) Select the program to be debugged
/hs (system debugging)
Menu: Program/Session -> Program -> Debugging

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 are having the problem
Start to debug a report when you think the problem is there (i.e.:long running report)
For debugging basis transactions usually the system debugging will be needed (/hs)

If you access the batch process via SM50 then you can use all features of the debugger
You can set dynamic/static breakpoints display or change fields ...
There is only one restriction: The ABAP statement break-point will not force the batch
process to stop. Only a syslog entry will be written (Breakpoint reached ...).

11
 Batch Debugging - Demo

Report ZDEBUGBATCH fails in batch

In dialog: In batch: The program fails

Precise debug access of a batch process:

If you debug a batch process then you can step through the code and use all debugger
features. But you can‘t use static breakpoints in order to force a batch process to stop at a
certain point. The batch process will not stop at any breakpoint !
Therefore this technique is not suitable to access the batch runtime precisely.
If you know the interesting source code then please insert an endless loop in the code right
before the interesting code.

i = 0.
While i = 0.
I = 0.
Endwhile.
... Interesting code....

If you start the job then the program will hang in your endless loop after some time.
If you now start debugging the you can be sure that you will access the batch job exactly at
your loop. Change i to e.g. 1 in the debugger and go on debugging

12
 Batch Debugging - Preparation for the
Exercise

If a program behaves different in batch and dialog:

Search globally for sy-batch

If the program distinguishes between sy-batch then

run the program in dialog and change sy-batch in the debugger to simulate batch
processing

e.g. memory management is different in batch and dialog

(visible via report RSMEMORY).
This behavior depends not on sy-batch.
Implement an endless loop in front of the important code
and jump via SM50 in the debugger. There you can check memory consumption
and the contents of e.g. internal tables.

If a program behaves different in batch input then search globally for sy-binpt.

To check the memory in the debugger:

Menue: Goto -> Display condition -> Memory Usage

13
 Batch Debugging - Exercise

Report ZDEBUGBATCH_UEBUNG
has no spool list in batch
In dialog: In batch: no Output ??

The program behaves different in batch and dialog:

Always check if you can find sy-batch in the program flow. You can run the program in
dialog and change sy-batch to ‘X’ (in the debugger) in order to simulate batch processing.

14
 Batch Debugging - Solution

Search for sy-batch in

ZDEBUGBATCH_UEBUN
G globally.

Change sy-batch in the debugger

to ‘X’ and you will enter form
output2:

There is no line with carrid = ‘IA’

-> No output (spool list) in batch

The application uses a dummy field to store the content of sy-batch.

Afterwards the program uses this dummy field to distinguish between a batch run and a
dialog run. In the first case form output2 is called. This form loops at an internal tablewhere
the carrier id = ‘IA’. Unfortunately there is no carrier id with this abbreviation.Therefore no
output is issued.
The dialog run calls form output1 which lists all LH flights -> List output.

15
 Debugging a Batch Job

Mark the Job in the Job Overview Screen (SM37)

Enter JDBG as OK-Code
Choose Enter
Proceed with F7 until you reach the ABAP program to be analyzed

The OK-code JDBG allows to analyze a batch job in Debug Mode. Advantages are:
Jobs can be debugged right from the beginning
If a Batchjob consists of more than one step, JDBG allows to analyze subsequent steps
consecutively (unless there is no termination of a step in a shortdump).
SY-BATCH is filled automatically by the system. It is not necessary to change the field
manually.
Handling of the Job in SM37 and the Batchjob itself can be analyzed in the same
debugging session

You can analyze any job, independent of the actual status.

Note that this is no test mode. Analyzing a job using JDBG will execute the job and might
perform changes on the database.

16
Start Debugging With a Shortcut

Create the shortcut with a SAPGUI higher than 4.5A

Generate Shortcut
on the desktop

Select ‚SystemCommand‘ from pull down

menu
Insert the debug command (/h or /hs)

Confirm with OK and the shortcut will be

placed on the desktop

17
 Start Debugging With a Shortcut

Drag the shortcut directly on the screen where you want to start debugging

Message ‚Debugging switched

on‘ will appear in the status field

This technique is really helpful if you are on a popup and want to start debugging.
You can‘t access the ok-field, therefore the shortcut technique is the only possible solution
to debug e.g. the ABAP of a popup directly.

Please assure (especially if you use a CITRIX client) that you have the (e.g.NT) permission
to save files on the desktop !

18
 Navigation in the Source Code

Increase program
section size

Display current
statement
Scroll source code

Control buttons ! Fixed point arithmetic inactive

F8 Continue (until Cursor)

F7 Return
F6 Execute
F5 Single Step

navigate through the coding:

Single step: one single command will be processed
Execute: one single command will be processed
(functions, forms etc. are treated as one command)
Return: all commands will be processed at once until the end of the
current routine
is reached
Continue: all commands will be processed until the current
cursor position or the next breakpoint or watchpoint

search buttons can be used to search within the coding

to navigate back to the next statement to be processed use the icon ‚display
current statement‘

to hide the view section click the icon ‚increase program section size‘

The flag Fixed pt. Arithmetic indicates whether the actual program uses fixed
point arithmetic or not. (adjustable via se38 -> Attributes)
If you use NO Fixed pt. Arithmetic then packed figures are similar to integers
independently of the DECIMALS settings.
19
 Example for Fixed Point Arithmetic

R/3 is not able

F8 to calculate ???

10050 +
1000
----------------
11050
set ‘.’ after 2 decimals:
110.50

Fixed-Point Arithmetic off:

The ABAP compiler doesn’t care about the decimals of the packed number and calculates
with integers.
If you display the figures then the compiler will set the point according to your decimals
declaration. But all calculations are performed without the decimals settings !!
You can check the FIXED-POINT-Arithmetic setting in the debugger or via SE38 in the
attributes of the program

As of release 6.10 Program attributes can be analyzed in the Debugger (Goto – Further
Information – Program Attributes). This includes attributes like
Fixed-point arithmetic
Unicode checks active
System program

20
 Navigation From the Debugger to a List Output

F5
Print next
write-line

You can always have a look at

the current list output .
Using this technique you can
control the output line after line

You navigate from the debugger to:

the current state of list-output ( GOTO -> Display condition -> Display List )
the current ABAP source ( Development -> ABAP Editor / Object Browser )
the screen painter (if you are in the flow logic of a Dynpro)

21
 Navigation Using the Active Call Stack

Double-click this
line in order to
navigate to this
function of the call
stack

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 in the
meantime. The switching itself is triggered by double-clicking on the desired level.

Please always keep in mind, that you only see the simple 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 task use ABAP Trace (SE30))

If system debugging mode is off, then you will not be able to switch into system modules
(switch on system debugging: /hs)

22
 Display Data in the Debugger

VIEW: FIELD

(2)
Double
click

VIEW: STRUCTURED FIELD (1)

Hex- Display
Press the magnifier icon.

VIEW: SINGLE FIELD

(3)
Double click

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 into 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 into any field in the structured field view or table view will lead you into the
detailed view of the single field.(3)

You can access the field directly too:

Insert: sflight-paymentsum.

You can access the different views also from the menu:
Goto -> Display data object ->
Single field (Ctrl + F2)
Structured field (Ctrl + F3)
Internal table (Ctrl + F4)

23
 Display Data in the Debugger

VIEW:
FIELD

(1)
Double-click

VIEW: STRUCTURED VIEW: INTERNAL

FIELD TABLE

(2)
Double-click

Starting from the fields view you can double-click into the field name to branch into the
table view (1)

A double click into any field in the table view will lead you into the detailed view of the field
(as shown in the last viewgraph (3))

You can access the field directly too:

Insert: my_struc-itab[] ([] means table contents / itab might be only the header line of the
table)

e.g.
my_struc-itab[2]-mandt will display the field mandt of the second line of the internal table
my_struc-itab

24
Exercise – Basic Navigation

Practice the navigation in the Debugger and test the display features using the
program ZDEBUGDISPLAY

Practice the sequential list output of the debugger

Start ZDEBUGDISPLAY with the debugger
Set a breakpoint at the statement WRITE
(Menu:Breakpoint -> Breakpoint at -> statement)
Step over the write statements (F5) and check the list output

25
 Manipulation of Variables

Each value displayed can be changed as well

edit the value (1)
click the pencil icon afterwards (2)

0 (2) change

(1) edit

If you enter a variable 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

It’s not possible to change the hex-values of fields.

If you allow an user to change variables via the debugger then this user can overcome
almost all authority checks.

26
 Manipulation of Internal Tables

Scroll Buttons for

switching between
the columns

Search Buttons for

searching in the
internal table

Delete if you want to

hide the column
(this does not delete
Header line (WA) the column)

Columns

Choose the table

operation you want
to perform

In order to manipulate internal tables you can either use the button ‚Table‘ or a double-click
on the internal table. The system will switch to table view screen. Within this view you can :
scroll horizontally and vertically through the table
hide columns by deleting the field in the column line
Shift column by inserting your column name instead of a displayed column name
This is merely a display functionality. Your changes have no effect on the internal table.
search through the lines by using the second search button. Positioning the cursor on a
certain line will use the line contents as search pattern.
The normal (first) search button searches in the source code.
insert, modify, delete an entry
Please keep in mind that the entry is only changed column by column (except the delete button)
If you want to insert a line first you need to click on insert first and to change every column of the row
afterwards.
If you want to change a whole row you need to do that column by column as well

modifying an internal table as a whole:

Menu path: Goto -> Display data object -> Structure Editor

27
Changing Internal Tables Using the Structure
Editor

Size of ITAB

28
Exercise - Change Variables

Change and use the other debug-features concerning internal tables.

Use itab[] in ZDEBUGDISPLAY > form fill_itab (after the select) as an example.
Modify some of the data objects and search for the modified data in the list
output of the program

29
 Static Breakpoints

Set Breakpoints directly in the editor (SE38)

position the cursor in a valid line
press the stop icon
the line will be marked

Set Breakpoints directly in the debugger

position the cursor in a executable line and double click
the stop icon will appear in front of the line

(1) hard coded breakpoints:

BREAK-POINT.
BREAK Hans. (Hans is the user name).
The first one leads to a stop for all user which are in a dialog session (on all servers)

The second one is a macro which is defined in Table TRMAC.

This macro is the short form of:
IF sy-uname = ‘Hans’.
BREAK-POINT.
ENDIF.

(2) If you use the ‘normal breakpoint’ in the editor (stop icon) then these breakpoints are
only valid for your user and your current logon !
(You will not see this break-point on another server !)

(3) If you set a breakpoint in the debugger then this breakpoint is only valid for the current
debug session. If you save the breakpoints then they are equal to editor breakpoints (->2)

Unfortunately it‘s not possible to set breakpoint in field-exits and conversion-exits. The
runtime will not stop there. You have to test your exits in an isolated test environment.
(SE37)

30
 Dynamic Breakpoints

Choose the criteria you

You can activate and You may want to save want to set the
deactivate a Breakpoint the Breakpoints for Breakpoint at
temporarily the next debugging
session

Set Breakpoint at :
statement e.g. select. You will find Breakpoints at all selects and cursor statements
event/subroutine: e.g. start-of-selection (event) or at a form of the actual program
function module: Insert the name at the function module. The Debugger will stop at the
first statement of the function module.
System exception: If your program uses the CATCH / ENDCATCH functionality then
you may oversee an occurring Dump. If you set Breakpoints at system exception the
debugger will stop at the statement where the skipped Dump occurred.

Deactivate / Activate Breakpoints

That’s not the same as deleting and setting breakpoints.
If you deactivate a Breakpoint then the Breakpoint is still there but the program will not stop
. This is a very convenient technique if you pass the Breakpoint several times. So for
example you can deactivate the Breakpoints then fill some screens and then after the
screens activate the Breakpoints again.

This technique allows you to reach the interesting part of the program as quick as possible
without loosing time because you always stop at the Breakpoint before the interesting
situation comes up.

31
 Possible Problems With Breakpoints

You must save the Breakpoints in the debugger if you want to

use them after your debugging session

You must restart the program after setting a static Breakpoint

in SE38. A running program will not see the new breakpoint.

The saved Breakpoints are only available for your

current logon. Other users or your second logon will not see
the Breakpoints.

If you set a dynamic Breakpoint at a statement then this

Breakpoint will not work in those programs which are not
loaded (called) yet.

Example for the last point:

We are in the program RSPARAM:(only one line of code)

SUBMIT RSPFPAR WITH ALSOUSUB EQ ALSOUSUB.

At this point we set a Breakpoint at WRITE.

The debugger will not stop because in the loaded program RSPARAM there is no WRITE.
The submitted program RSPFPAR is not yet loaded therefore there will be no Breakpoints
at the WRITE statements in this program.
If you access the program RSPFPAR after the commit and now set a Breakpoint at WRITE
then the program is loaded and you will stop at each WRITE statement.

32
 Manipulation of Breakpoints

Counter

In the view ‚Breakpoints‘ you can

check and change the list of active Breakpoints
assign a counter to a specific Breakpoint, which will cause the
program to stop after the specified occurrence of the Breakpoint

The Breakpoint overview allows you to delete e.g. only the dynamic Breakpoints at WRITE.
So you don’t 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 the
runtime a Dump occurs at an INSERT statement which complains about a too big internal
table and a lack of memory.Now you have the problem to debug the program.
You place a Breakpoint at the valid INSERT statement, but unfortunately the
INSERT´statement is executed thousands of times.

Now you can use the Count-technique.

Set the counter e.g. to 1000 and execute. If you get the Dump then decrease the value to
500 then 250 .... With this technique you will be able to debug the exact moment when the
error occurs.

33
 Watchpoints

If you set a watchpoint on the field matnr (matnr = ‘1234’) then

the debugger stops as soon as matnr contains the value
‘1234’.

If you do not specify a condition then the debugger stops as soon as the field
matnr changes.

Watchpoint: Matnr = 1234

Program flow

Matnr = 0000 Matnr = 0120 Matnr = 1234

Watchpoints are very dynamic Breakpoints.

You can specify a field which should be monitored and you can specify a stop condition.

The system will inspect the memory address which is connected to the field name
and will compare the value in this memory address with your condition.
As soon as the condition and the current value match the debugger stops.

34
 Creation of Watchpoints

In the view ‚Watchpoints‘ you can

check the list of active Watchpoints
create Watchpoints
specify the logical operator between the Watchpoints to stop either when all
specified conditions are true or only one of them

Create
LOCAL
or
GLOBAL

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 condition of the variable the system should stop
(<,>,<>, <=.>=). Even the comparison to another variable is possible

If you create more than one Watchpoint you can link them together with AND and OR.

Local and global Watchpoints:

The debugger always looks at the memory address of the Watchpoint-field.
Some special parameters and fields are shared between programs.
(e.g TABLES, COMMON PART, SY-fields)
This means two program look at the same memory address (e.g. sy-subrc).
If you use local Watchpoints then 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 then you will always stop if the memory content changes
independently of the program.

35
Exercise 1

Run transaction VA01 with

order type = TA / sales organization = 0001 /
distribution channel = 01
Press Return : On the second screen you find
the date field: Req.deliv.date (e.g.10.04.2000 )
Please find the source line where the value is set
(Use F1 + technical info to get the field name / use a Watchpoint
Start VA01 via Se80 if your Watchpoint does not work)

You will find a function which sets the value:

Call Function 'PERIOD_AND_DATE_CONVERT_OUTPUT'

Exporting
Internal_Date = Vbak-Vdatu <<<<<<
Internal_Period = Vbak-Vprgr
Importing
External_Date = Rv45a-Ketdat <<<<<<
External_Period = Rv45a-Kprgbz.

Additionally, please evaluate where the input variable Vbak-Vdatu is set.

Compare the result if you use a local Watchpoint and a global Watchpoint .

36
 Exercise 1 - Solution

VBAK-VDATU is a shared Tables area. This means at least two programs look on the
same VBAK-VDATU and they can change it mutually.

If you use a local Watchpoint then you will only observe changes in program SAPMV45A.
In our case you only see, that VBAK-VDATU is changed if you reenter SAPMV45A.
Therefore you stop at the first line of the called form.

If you use a global Watchpoint then ALL changes are observed and therefore you get the
really interesting change in SAPFV45K.

37
Watchpoint on Table Reference - Demo

Executing program ZDEBUGWATCH leads to the Dump

TSV_ILLEGAL_REFERENCE.
Where is the problem ???

38
 Watchpoint on Table Reference - Demo

Definition of an internal table with a header line:

Data: itab like sflight occurs 0 with header line

Display options of internal table itab in debugger:

itab header line

itab[] table body

*itab[] table header

&itab[] table reference

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. The body of an
internal table stores the various rows of the internal table. You get it displayed in the Tables
Tab of the debugger. The header line is a structure that has the same name and the same
line type as the internal table. During program execution it can be used as a workarea for
processing individual records of the internal table.

Besides these the system needs to store some administrative information on the internal
table (e.g. the number of rows). This administration is stored in the table header *itab[].

The table reference &itab[] is pointer which points to the memory area, where the table
header is stored. Without knowing this memory area, the runtime environment cannot
execute statements on internal tables (e.g. loops …)

Sometimes the table header or the table reference gets destroyed by some dirty ABAP
statement. We are able to analyze this using Watchpoints!

39
Solution for Demo

Create a Watchpoint on the table

reference for the destroyed internal table
at the beginning of the program
The reference of itab is destroyed

&itab[] before the

guilty statement

The Watchpoint is reached

at this statement

&itab[] after the

guilty statement

40
 Solution for Demo

DATA C(23) TYPE C.

DATA ITAB LIKE SFLIGHT OCCURS 0 WITH HEADER LINE.
FIELD-SYMBOLS: <F>.

C = 'Some flight information'.

SELECT * FROM SFLIGHT INTO TABLE ITAB.
ASSIGN C+12 TO <F>. <<<<<<<<<<<< the length specification is missing
<F> = 'info'.
1 12 23 35

Some flight information

Field c Table reference of itab[]
ASSIGN C+12 TO <F>.
<F> Is identical to:
ASSIGN C+12(23) TO <F>.
1 12 23 35

Some flight info20202020202020202020202020

Field c Table reference of itab[]

<F> = 'info'.
<F>

DATA C(23) TYPE C.

DATA ITAB LIKE SFLIGHT OCCURS 0 WITH HEADER LINE.
FIELD-SYMBOLS: <F>.

C = 'Some flight information'.

SELECT * FROM SFLIGHT INTO TABLE ITAB.
ASSIGN C+12 TO <F>. <<<<<<<<<<<< the length specification is missing
<F> = 'info'.
WRITE : / C. skip 2. " print headerline
…

After the assign the Field symbol <f> covers the region from c+12(23).
Therefore <f> covers also the region BEHIND the field c! After the field c the internal table
reference starts. A part of this reference is covered by the field symbols (red area).
If you now change the content of the field symbol you will destroy the content of a part of
the table reference. In our example you write ‘info’ from the position 12 in the c-string. The
rest is filled with SPACE (hex20). Therefore the area of the table reference which is
covered by the field symbol will contain the hex value hex20.

Solution: Use a length specification with the ASSIGN statement, so that the compiler will
not use the default length (length of the field c):

ASSIGN c+12(4) to <f>.

41
Exercise 2

Now please try to explain the following behaviour:

The program ZDEBUGPROBLEM1 is started with

carrid = LH

But the program displays the following list:

I found a flight in the database

The first flight I found is:

carrid =
connid = 0000
fldate = 00.00.0000

42
 Solution - ZDEBUGPROBLEM1

In the external form my_flight is declared too.

This structure is not filled yet !

A Watchpoint will not help here.

This exercise should stress the point that you should always understand the problem
before starting to use special debug tools.

The problem is that we have two programs ZDEBUGPROBLEM1 and

ZDEBUGPROBLEM1EXT. Each of these programs has defined the structure
my_flight separately . Therefore if you fill the structure in program ZDEBUGPROBLEM1
and switch to the other program (via external perform) then the second structure with the
same name is still empty !
You must pass the value via the interface of the external perform from one program to the
other.

43
 Debugging in a Production Client

Start Debugging -> DB Commit

UPDATE line1
UPDATE line2
...
...
UPDATE line3
UPDATE line4
...
Rollback Work
Field 1 Field 2 Field 3 Field 4

The first 2 Updates are on the database.

A following Roll back has no effect on this data.
Only updates of line 3/ line4 are Rolled back

If you jump in the debugger during a running transaction (e.g. via SM50) then the debugger
screen pops up. As usual each screen switch is connected with a database commit.
This database commit is executed because after a screen switch you are rolled out and
perhaps rolled in in a totally different work process. Therefore the database must be
consistentwhen leaving a process (DB commit)

If a DB commit is executed then all direct updates are stored on the database.
The CALL FUNCTION IN UPDATE TASK are not executed (They are only launched if the
ABAP statement COMMIT WORK is executed).

Assume we enter the debugger after two direct updates (line1 & line2).
The debugger screen executes a DB-commit.
-> line1 and line 2 are now definitely updated on the database.

Afterwards two additional UPDATES (line3/4) are executed. The following ROLLBACK will
cancel these updates but unfortunately the first two updates are committed and therefore
will remain on the database ->DATA INCONSISTENCY

44
 Debugging in a Production Client

Debugging in a production client -> Locks

Normal mode Debug mode

Debugge
r

Field 1 Field 2 Field 3 Field 4

In a debug mode
The lock will be hold until you
exit debugging or you execute a
DB lock is released DB commit / Rollback explicitly.

Problem: Locks during debugging in the debug mode

Example: You edit an ABAP program. After saving you omit generation and go directly into
the debugger. The system checks the state of the program and recognizes that the
program needs generation. Therefore at the beginning of debugging the program will be
generated.
But there will be no Commit in the production client. Therefore all locks on the special lines
of the ABAP-Tables (D010L..., D010S...) are present.
If now someone changes the same program and wants to save then he will only see the
hour glass until his colleague ends debugging and the locks are released.
Therefore the debugger presents the possibility to execute an explicit COMMIT and
ROLLBACK to release locks. But you are responsible for database consistency!

Keep in mind: A DB commit during debugging in a SELECT...ENSELECT block destroys

the current DB-Cursor and you will receive a Dump DBIF_RSQL_INVALID_CURSOR .
Therefore it’s not possible to debug SELECT...ENDSELECT blocks if you are not in a
DEBUG-mode.

45
Debugging in a Production Client

How to debug safely (no 100% guarantee)

Start debugging

Check in SM50 whether in debug mode

If not: leave debugging and try later again
If yes: debugging is possible

If you want to stop (abort) choose DB rollback from menu

Leave debugging

46
 Demo: Debugging in a Production Client

Run Program ZDEBUG_DB01 in several modes

2 Processes are hanging because USER ZSU222 is debugging ???

DB01

Programsource of ZDEBUG_DB01:...

11 READ TABLE ITAB WITH KEY CARRID = 'LH'.

12 SELECT SINGLE FOR UPDATE * FROM ZDEBARFC <<<<<<<<< LOCK THIS

LINE OF ZDEBARFC

13 WHERE CARRID = ITAB-CARRID AND

14 CONNID = ITAB-CONNID AND

15 FLDATE = ITAB-FLDATE.

16

17 BREAK-POINT.

If you stop at the breakpoint and you are in a debug mode then you will hold the DB lock on
the specified line of ZDEBARC until you exit debugging or you execute an explicit DB-
COMMIT / Rollback. All other programs which want to update or lock the same line must
wait until you release the lock. This wait situation can be observed via transaction db01.

47
Summary

Now you are able to:

Start the ABAP debugger
Navigate in the ABAP debugger
Use the display options of the ABAP debugger
Use Breakpoints and Watchpoints

Avoid causing problems when debugging

in a productive client

48
Copyright 2009 SAP AG
All Rights Reserved

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, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.
IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z, System z10, System z9, z10, z9, iSeries, pSeries, xSeries, zSeries,
eServer, z/VM, z/OS, i5/OS, S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise Server, PowerVM, Power Architecture, POWER6+, POWER6, POWER5+,
POWER5, POWER, OpenPower, PowerPC, BatchPipes, BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex,
MVS/ESA, AIX, Intelligent Miner, WebSphere, Netfinity, Tivoli and Informix are trademarks or registered trademarks of IBM Corporation.
Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.
Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other
countries.
Oracle is a registered trademark of Oracle Corporation.
UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.
Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc.
HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.
Java is a registered trademark of Sun Microsystems, Inc.
JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.
SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign, 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 other countries.
Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business Objects products and
services mentioned herein as well as their respective logos are trademarks or registered trademarks of Business Objects S.A. in the United States and in other countries.
Business Objects is an SAP company.
All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only.
National product specifications may vary.
These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only,
without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group
products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed
as constituting an additional warrant.

49