advanced debugging

1

Analyse Problem - Using ABAP DebuggerAdvanced Debugging

Active Global SupportMarch 2009

2

© SAP 2009 /

Course Content (current Highlighted)

Introduction

Debugger I

Screens

ABAP Messages

Debugger II

Performance Trace

Updates

User ExitsDynpro Trace

Syslog

Batch Processing

ABAP Trace (Runtime Analysis)

Dump Analysis

R/3 Basis Technological Overview

Memory Management

3

© SAP 2009 /

Unit Objectives

This unit will prepare you to perform the following tasks: Use advanced debugger features for problem analysis

4

© SAP 2009 /

Debugger 2 - Expert Features of the Debugger

How do the ABAP gurus extract all these info from the debugger

5

© SAP 2009 /

Settings

Menu: Settings ->

Display and change all

Detailed information about these settings are available in the extended help of the debugger

Some Remarks about the Settings ‚Runtime warnings‘:If the ABAP runtime environment issues a kernel warning then the parameters abap/warnings will control the reaction of the system.ABAP kernel warnings are one step below a real Dump. This means a failure has been detected but nevertheless the program flow can go on.

abap/warnings: Accepts the following values: - ignore: No action taken. This is the only permissible value for production systems. - list : Warnings are listed and can be displayed in the ABAP/4 debugger. - dump : Warnings result in abnormal terminations and an ABAP/4 short dump.

With the debugger settings WARNINGS you can set the behavior explicitly for your session.It‘s a good idea to switch Warnings on in the debugger because you may get some additionally info from skipped kernel warnings. The debugger will stop at each kernel warning and you can have a look at the warning in the settings->display and change menu.If you check Dump for Warning then the debugger will not stop at a warning but you will get a short dump

6

© SAP 2009 /

Settings

System programs are outlined by blue color in the call stack. Navigating into these programs is only possible with system debugging (/hs). Otherwise you will receive the error message: ‘Display only possible using system debugging’

The system program is skipped during debugging if you don‘t use system debugging.

System Debugging on/off

SE38/Attributes /Display

System debugging can be switched on via menu Settings or by /hs in the ok-code field.

If you debug a call function statement but the runtime skips the function then 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 < 45A the system modules are not visible in the call stack if you use normal debugging.

7

© SAP 2009 /

Demo: System Debugging

Run ZDEBUGSYSTEM and understand why the first function is not reached.

See the difference between System Debugging on / off

8

© SAP 2009 /

Debugger / 2 - Settings

Memory Monitoring on/off

If you have problems like these then you deal with memory overwriting in the kernel. The memory monitoring is a good tool for the first analysis.

Dev_files, (ST11)

Syslog, (SM21)

Dump, (ST22)

Memory monitoring is essential if you have to deal with SYSTEM_CORE_DUMPED or canceled workprocesses.Please activate the memory at the beginning of the guilty transaction and press F8 to continue. The debugger will stop at once if it detects an overwritten memory segment.

Please forward the guilty statement (program/line) to the ABAP language group for further analysis. Additionally please add the C-Stack (from the Dump or the dev-file).See also Note 193988.

The memory check is performed after each ABAP statement and therefore performance will be really bad during monitoring.

The memory monitoring has no opportunity to find the error if the memory overwriting and the access of the corrupted memory address are performed during one ABAP statement.The Core will happen before the system can check the memory.

9

© SAP 2009 /

Settings

Update Debugging onIf you enable the update debugging option, all update function modules are processed in the Debugger after the COMMIT WORK statement.This is the only possibility to debug the update processduring a running transaction

In background task: Lock Release onYou can lock the sending of an asynchrony function call. (CALL FUNCTION ... IN BACKGROUND TASK. ) This locked function is then available in transaction SM58 for debugging.

Transaction SM58

Position your cursor on the function module.Then choose Edit -> Debug LUW

If you locked a background function in the debugger then you will find this function after the COMMIT WORK in transaction SM58.

If you use the normal asynchronous update then after a Commit Work the update work will be done by another work process (update work process). Therefore the debugger can‘t debug the update procedure.

If you switch on Update Debugging then after the COMMIT WORK theupdate is executed in YOUR process and therefore the debugging can go on.

10

© SAP 2009 /

Settings

Asynchronous update - What’s that ?

FUNCTION ‘ABC’ . ...

UPDATE ZDEBARFC....

ENDFUNCTION.

Update WP

CALL FUNCTION ‘ABC’ IN UPDATE TASK EXPORTING ...

COMMIT WORK.

Dialog WP

Field 1 Field 2 Field 3 Field 4

VBDATAVBMOD

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 useCALL FUNCTION... IN UPDATE TASK .

If you call a function which does the update in Update task then this function is not called instantly but 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.

11

© SAP 2009 /

Settings

Why do I need Update debugging ?

The debugger is attached to one process and cannot jump to the update process

Update is launched

COMMIT WORK

Debugger

If you use the normal asynchronous update then after a Commit Work the update work will be done by another work process (update work process). Therefore the debugger can‘t 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 don’t need update debugging.

12

© SAP 2009 /

Settings

Solution : Update Debugging executes the updates in the Dialog process

COMMIT WORK

Debugger

Switch on Update Debugging

If you use the normal asynchronous update then after a Commit Work the update work will be done by another workprocess (update workprocess). Therefore the debugger can‘t debugthe 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.

13

© SAP 2009 /

Exercise and Demo - Settings

Demo: Update Debugging (ZDEBUGUPDATE)Demonstrate the Debug behavior with switched on and off Update debugging .

14

© SAP 2009 /

Settings - TRFC Debugging

TRFC - What’s that ?

FUNCTION ‘ABC’ . ...

UPDATE ZDEBARFC....

ENDFUNCTION.

NEW YORK

CALL FUNCTION ‘ABC’ IN BACKGROUND TASK DESTINATION ‘NEW_YORK’EXPORTING ...

COMMIT WORK.

Walldorf


ARFCSSTATE ARFCSDATA


ARFCSSTATE ARFCSDATA

Execute

The function name and function data is stored in DB-tables under a unique transaction id (DB-tables: ARFCSSTATE / ARFCSDATA).

AT COMMIT WORK :The data which is stored in ARFCSSTATE / ARFCSDATA) is transferred to the target system.Afterwards the functions are executed on the remote system.

All TRFC functions with the same Destination build one LUW

The remote system has not to be available at the commit work event.The system will try several time to execute the LUW. If the system is still not available then a batch job (RSARFCSE) is scheduled which will try to connect e.g. in intervals of 30 minutes.

The TRFC-technique is e.g. used to update tables asynchronously on a remote system.

The status of the TRFC modules is visible via Transaction SM58

15

© SAP 2009 /

Settings

Why do I need ARFC Debugging (Background)

COMMIT WORK

Debugger

RFC to the system in New York

The debugger is attached to one process and cannot jump to the WP in New York

If you use the CALL FUNCTION IN BACKGROUND TASK then after a Commit Work the update work will be done by another workprocess perhaps in a remote system in NEW YORK. The debugger cannot follow the request to NEW YORK because the debugger is attached to your dialog process.

16

© SAP 2009 /

Settings

Solution: Don’t send the the update request to the target system. Store this info in sm58 and use RFC debugging afterwards

COMMIT WORK

Debugger

Switch on tRFC-Debugging

RFC to the system in New York

If you switch on In background Task: ‘Do not process’ then after Commit work the RFC requests are not send to the remote system but stored in the current system. They are visible in transaction SM58. There you will find the option to debug the LUW.With RFC-debugging you can now debug the update on the New York system.

17

© SAP 2009 /

Exercise and Demo - Settings

Demo: TRFC DebuggingRun ZDEBUGARFC in debug mode. Debug the program with switchedoff tRFC debugging. Check transaction sm58-> any tRFC’s waiting ?Do the same with switched on tRFC Debugging.

Exercise: Update Debugging (ZDEBUGUPDATE)The program should change the price of allflights to 1000 and seatsmax to 100.But unfortunately it does not !Please use update debugging to get the error.What’s your suggestion to correct the program.

18

© SAP 2009 /

Solution of the Update Problem

These forms fill the internal table itab[]which is transferred for update to the functionZ_DEBUG_UPDATE.

The internal table itab[] is empty when thefunction Z_DEBUG_UPDATE is registered.Therefore itab[] will be empty when the function is executed after Commit Work.

After the COMMIT WORK the forms form1, form2 and the function Z_DEBUG_UPDATE are started.

Purpose of the programnPreparation: fill table zdebarfc with default values (copy of sflight).

nPerform form1 on commit. Form1 selects all flights of zdebarfc into an internal table itab[] and changes all prices to 1000 $

nPerform form2 on commit. Form2 changes the internal table itab[] and sets all SEATSMAX to 100

nCALL FUNCTION 'Z_DEBUG_UPDATE' IN UPDATE TASK TABLES L_ITAB = ITAB[] The update function gets internal table itab as input and shallupdate the database table ZDEBARFC from table itab[].

nBut unfortunately if you debug the update function you observe that itab[] is empty. Therefore the update function will not change ZDEBARFC.

Problem: The interface with all parameters of the update function is saved during the registration process. Unfortunately the table itab is filled AFTER COMMIT WORK because the filling forms (form1, form2) are called on commit. This implies that during registration itab[]is still empty. Therefore the update function which will be launched after the commit has nothing to update. Therefore ZDEBARFC remains unchanged.

19

© SAP 2009 /

Expert Display Features

Access The System Area:Menu: Goto - System - System areasOK Code = dis

VERSION System Information PROGRAMS Information about loaded programs

(equal to Goto -> Display condition -> Aktive Programs) SMEM SAP Memory contents / SET PARAMETER .... / User Parameters DSEG Used data segments in the actual internal mode.

(Intersting if you exceed the 32k limit. In one roll area only 32 k Data Segments are allowed)

MEMORIES ABAP Menory contents / EXPORT ... TO MEMORY ID ... DATASETS Open datasets and their condition. (OPEN DATASET... / TRANSFER ... )PXA Local PXA contents . Which programs are loaded...

some more inforamtion compared to transaction : ST02 / Detail Analysis Menue / Program / Buffered Objects / PXA buffer technical

PXAHEAD Statistics about the local PXA some more inforamtion compared to transaction : ST02 / Detail Analysis Menue / Program

20

© SAP 2009 /


Doubleclick

Show Detailed Release Info

You can get a subset of this information via SM51/Release notes or Menu:

System -> Status

21

© SAP 2009 /

...

DATA c(20) TYPE c VALUE 'Debugger session'.

SET PARAMETER ID 'ABC' FIELD c.


SAP Memory / SPA - GPAEXPORT TO MEMORY / SET PARAMETER ...

Double-click

The contents of the SAP memory is interesting if you want to check whythe user parameter settings (SU01 / Parameters) don‘t work in a special transactionthe ABAP statement GET PARAMETER ... does not get the parameter ...

22

© SAP 2009 /


ABAP Memory

...

DATA c(20) TYPE c VALUE 'Debugger session'.

EXPORT c TO MEMORY ID

'DEBUGGER_KURS'.

Double-click

Double-click

If you have problems with the ABAP statement IMPORT FROM MEMORY because it does not fill your fields in a correct way then you can look directly in the ABAP memory in order to check it‘s contents.

Use the ABAP-stack to step back some function/form calls and check the ABAPmemory simultaneously. This is one way to find e.g. the place where someone overwrites your ABAP memory contents. (via another EXPORT TO MEMORY with the same ID)

Another way would be a SE30 Trace. Search for EXPORT TO MEMORYin the CALL HIERARCHIE.Set Breakpoints at these statements and start the valid transaction. Check the memory contents at every interesting EXPORT TO MEMORY statement.

23

© SAP 2009 /

DATA: root(30) TYPE c VALUE ’zdebugtest’.

OPEN DATASET root FOR APPENDING IN TEXT MODE.

DO 100 TIMES. TRANSFER 'ABCDEF‘ TO root.

ENDDO.

CLOSE DATASET root.


Display Dataset StatusTRANSFER / OPEN DATASET ...

This functionality displays the conditions of all open datasets.OPEN The file handle is openEND The READ statement reached the end of file symbolERR Error occurredPOSITION Read/Write PositionSIZE actual file sizePERMISSION normal permission string

Unfortunately there is a big disadvantage of this display functionality:Every new screen executes a DB-Commit which closes all datasets.Therefore please switch to the system areas right before the interesting DATASET statement and press F5 (single step) to see the effect of the statement. Unfortunately this (F5 in the system area) is only possible in R/3 Releases >31I.

The Commits in the debugger involves that it‘s impossible to debug the dataset handling if you use pipes. (->Dump DATASET_PIPE_CLOSED )

SAPNet-Note 0138711 deals with almost all known DATASET problems.

24

© SAP 2009 /

Exercise - SYSTEMAREA

Program ZDEBUGEXPORT doesn’t display the list of LH-flights.

Where is the problem ?

Purpose of the program ZDEBUGEXPORT:The program selects all flights into an internal table itab.This table is exported to the ABAP memory.Another report is submitted and the internal table is imported from memory.Now loop at the imported table and print the content.

Unfortunately the Import fails and the internal table is therefore emptyCheckout why the import fails.

25

© SAP 2009 /

Exercise - SYSTEMAREA

After form xyz the ABAP memory id Debugger_Workshop is cleared.

After the Export the internal table itab[] is visible in the ABAP memory.

Solution: In form xyz (zdebugexport2) a second export to memory into the same ID is executed. This export to memory exports an empty internal table.Therefore after this export the memory id contains no data and the following Import fails.

26

© SAP 2009 /

Examples/Exercises

Optional: (If you have some spare time) Make yourself familiar with the expert display features in the debugger

System areasZDEBUGSYSTEMAREA

27

© SAP 2009 /

DATA INT TYPE I.

CATCH SYSTEM-EXCEPTIONSCOMPUTE_INT_ZERODIVIDE = 1.INT = 1 / 0.

ENDCATCH.

DATA INT TYPE I.

INT = 1 / 0.

No error occured

Demo-program: ZDBG_01

Systemexception

Since release 40B application programmers can use a special technique to catch run time errors. This may lead to problems during analyzing a problem, because you don’t get a dump at the faulty statement. The application handles the error situation itself.

28

© SAP 2009 /

DATA INT TYPE I.

CATCH SYSTEM-EXCEPTIONS COMPUTE_INT_ZERODIVIDE = 1. INT = 1 / 0.

ENDCATCH.

Debug the odd program and set a breakpoint on System Exception

You stop where the dump would have been launched

sy-subrc = 1 !!

Systemexception

You can set a breakpoint on System Exception to assure that you will see each caught Dump. The Dump text is displayed on the status bar when you double-click on the warning sign.The sy-subrc is set according to the CATCH Statement (COMPUTE_INT_ZERODIVIDE = 1 -> sy-surc = 1 if the error occurs)

Keep in mind that we do not support a ‘deep catch’ technique. This means if you call a function in the catch block and an error occurs in this function then this error is notcaught.

29

© SAP 2009 /

Error classes of catchable runtime errorsarithmetic errorsThis class comprises runtime errors that can occur in arithmetic expressions. It does not include errors caused by converting data types in arithmetic expressions.

key words– ADD, ADD-CORRESPONDING, COMPUTE, DIVIDE, DIVIDE-CORRESPONDING,

MULTIPLY, MULTIPLY-CORRESPONDING, SUBTRACT, SUBTRACT-CORRESPONDING

examples– COMPUTE_INT_ZERODEVIDE, COMPUTE_BCD_OVERFLOW, ...

conversion errors This class comprises runtime errors that can occur when you convert one data type into another.

key words – ADD, ADD-CORRESPONDING, COMPUTE, DIVIDE, DIVIDE-CORRESPONDING,

MOVE, MOVE-CORRESPONDING, MULTIPLY, MULTIPLY-CORRESPONDING, PACK, SUBTRACT, SUBTRACT-CORRESPONDING, UNPACK

examples– (CONVT_NO_NUMBER, CONV_OVERFLOW, ...)

Systemexception - Technical Information

More info contained in the online help:

Example: ADDCatchable runtime error BCD_FIELD_OVERFLOW: Result field too small (type P). BCD_OVERFLOW: Overflow with arithmetic operation (type P) COMPUTE_INT_PLUS_OVERFLOW: Integer overflow when adding.

Non-catchable runtime error BCD_BADDATA: P field does not contain correct BCD format.

30

© SAP 2009 /

Detailed description:Execute ZDBG_02 using SE38Use Input ‘123’ in the selection screen and afterwards ‘abc’. Debug the program and change it if you want to

Systemexception - Exercise: „Debug theProgram “

Check:Is the function raising an exception?Step into the function to determine what is happening

31

© SAP 2009 /

Systemexception - Solution

Start from SE38

without catching the systemexception a shortdump would havebeen raised!

F8

11

22

F8

Change to abc

The system exception is specified by using the error class

32

© SAP 2009 /

Sharing Relationship

Sharing relationship between programs

Extra hard chapter

Application programmer:

“In my test system I fill a Tables area in a form and when I return to the calling program then the value is unchanged.

But on the customer system the value is changed after returning to the calling

program !!”

Program groups in ABAP:If you start a report (Type 1) or a Modulepool (M) then this program is the head of a program group. If you know execute an external perform in a subroutinepool or another program then this program is loaded and is part of the current program group. (The same is valid for e.g.a call subscreen ).The LOAD event is essential. Only if you are the first caller of the program ( and therefore the program is not present yet) then it must be loaded. After this load event this program will be part of your program group. In other words:The LOAD event is essential to decide if e.g. a subroutinepoolwill be part of your program group or is already a member of another program group.But there is one exception: if you call a function or another part of a FUNCTION GROUP then this function group will not be part of the current program group, but will create a new parallel existing program group.

COMMON PARTs / TABLESUsual global DATA declarations are only visible and accessible in the current program. But if you use COMMON PARTs or TABLES areas then these variables will be shared between programs. This implies if program A changes the TABLES area MARA then this change is also visible in program B.This is data transfer between programs without using an interface.

SHARING rulesAll programs which are members of a program group and include tables areas or common parts with the same name will share these variables. This means only one memory address is used for the variable and all sharing programs look and change on the same address.This implies that the SEQUENCE of performs / calls can influence the sharing relationship !

33

© SAP 2009 /


Active programs - sharing tables

REPORT zbgtest2 .

TABLES: sflight.

FORM xyz. SFLIGHT-CARRID = 'XX'.

ENDFORM.

REPORT zbgtables .

TABLES: sflight.

sflight-carrid = 'LH'.

WRITE: SFLIGHT-CARRID.

PERFORM xyz(zbgtest2).

CALL FUNCTION 'ZBGTMP'.WRITE: SFLIGHT-CARRID.

TABLES: sflight.

FUNCTION zbgtmp. *"------------------------------*"*"Local interface: *"------------------------------

sflight-carrid = ‘AA'.


OUTPUT

sflight-carrid = LH

sflight-carrid = XX

SAPLZZBG

Example ZBGTABLES:Report ZBGTABLES executes an external perform into ZBGTEST2.-> ZBGTEST2 is in loaded and now a part of the program group ZBGTABLES.-> These two programs share the tables area sflight.Now function ZBGTMP of function group zzbg is called.-> Function groups build a new program group -> second program group saplzzbg-> This function executes an external perform in ZBGTEST2 but this program is already loaded and is already a member of program group ZBGTABLES. -> Therefore the the function group WILL NOT SHARE with ZBGTEST2.At the end we have two tables areas SFLIGHT. One of the program group ZBGTABLES which is shared between ZBGTABLES and ZBGTEST2 and the other of the function group ZZBG. If we understand this sharing relationship then we can predict the value of SFLIGHT-carrid during the program flow:ZBGTABLES: we start with sflight-carrid = LHexternal peform ZBGTEST2: SFLIGHT-CARRID is still LH because ZBGTABLES and ZBGTEST2 share SFLIGHT.SFLIGHT-CARRID is set to ‘XX’. Return from external perform:ZBGTABLES: SFLIGHT-CARRID is still ‘XX’ because ZBGTABLES and ZBGTEST2 share SFLIGHT. Call function SAPLZZBG: SFLIGHT-CARRID is initial (New program group - no sharing) SFLIGHT-CARRID is set to ‘AA’.external peform ZBGTEST2: SFLIGHT-CARRID is still XX because SAPLZZBG and ZBGTEST2 don NOT share SFLIGHT.Return from external perform: SAPLZZBG: SFLIGHT-CARRID is still AA - SAPLZZBG and ZBGTABLES do not share.Return from call function: ZBGTABLES: SFLIGHT-CARRID is still XX (no sharing between zbgtables / saplzzbg)

34

© SAP 2009 /

Memory

Prg1Prg1 = XX

Prg3Prg2

Prg2 = AA



Program 2

Program3

Local fields (DATA:)Tables / Common part

Form ABC

Program 1

PERFORM ABC (PROGRAM3)

Call function x

function xPERFORM ABC (PROGRAM3)

Essentials about Sharing:Only Tables Areas and Common Parts with equal names are affectedThe Load event is the essential event which builds up the sharing relationshipIt’s NOT essential whether this Load Event is caused by an external perform or e.g. call screen(the screen is in another program).So for example a statement like PEFORM X_Y_Z IN PROGRAM ZHANSON IF FOUND will load the program ZHANSON to check if the form X_Y_Z i available. But in spite of the fact that the form x_Y_Z does not exist now the sharing between the calling program and ZHANSON is established just because of the Load Event.

35

© SAP 2009 /


Active programs - debugging

In group with =

who shares his TABLES/ COMMEN PARTS with whom

This Sharing behavior is really complicated (note 135482 )Therefore the debugger offers an assistance tool to analyze the sharing relationship.

Choose GOTO->Display condition -> Active programs

You will get a list with all loaded (active) programs.

If two programs share there mutual TABLES or COMMEN PART areas then they are ‚in grp. with‘. (in group with - they build program group)

This means the actual program (pointer) ZBGTEST2 is in group with No. 1.No. 1 corresponds to program ZBGTABLES.

36

© SAP 2009 /



REPORT zbgtest2 .

TABLES: sflight.

FORM xyz. SFLIGHT-CARRID = 'XX'.

ENDFORM.

REPORT zbgtables .

TABLES: sflight.

sflight-carrid = 'LH'. WRITE: SFLIGHT-CARRID.

CALL FUNCTION 'ZBGTMP'.

PERFORM xyz(zbgtest2). WRITE: SFLIGHT-CARRID.

TABLES: sflight.

FUNCTION zbgtmp. *"------------------------------*"*"Local interface: *"------------------------------

sflight-carrid = ‘AA'.


OUTPUT

sflight-carrid = LH

sflight-carrid = LH

Example ZBGTABLES: Changed Call order Function ZBGTMP of function group zzbg is called.-> Function groups build a new program group -> second program group saplzzbg-> This function executes an external perform in ZBGTEST2 . This is the first time that program ZBGTEST2 is requested. The program is loaded ! This implies that ZBGTEST2 is now a member of the program group SAPLZZBG.-> Therefore the the function group WILL SHARE with ZBGTEST2.-> Afterwards we return from the call function and we execute the external perform

from zbgtables into ZBGTEST2. But now we are the second caller and ZBGTEST2 isalready loaded and a part of program group SAPLZZBG. Therefore ZBGTABLES and ZBGTEST2 will not share ! If we understand this sharing relationship then we can predict the value of SFLIGHT-carrid during the program flow:ZBGTABLES: we start with sflight-carrid = LHCall function SAPLZZBG: SFLIGHT-CARRID is initial (New program group - no sharing) SFLIGHT-CARRID is set to ‘AA’.external peform ZBGTEST2: SFLIGHT-CARRID is AA because SAPLZZBG and ZBGTEST2 share SFLIGHT. SFLIGHT-CARRID is set to ‘XX’Return from external perform: SAPLZZBG: SFLIGHT-CARRID is XX - SAPLZZBG and ZBGTABLES share.Return from call function: ZBGTABLES: SFLIGHT-CARRID is still LH (no sharing between zbgtables / saplzzbg)external peform ZBGTEST2: SFLIGHT-CARRID is still XX because ZBGTABLES and ZBGTEST2 do not share. SFLIGHT-CARRID is set to ‘XX’.Return from external perform: ZBGTABLES : SFLIGHT-CARRID is still ‘LH’ because ZBGTABLES and ZBGTEST2 do not share SFLIGHT.

37

© SAP 2009 /



Program3Local fields (DATA:)

Tables / Common part Form ABCMemory

Program 2function x


Program 1


Call function x

Prg1Prg1 = LH

Prg3

Prg2Prg2 = XX

38

© SAP 2009 /


Active programs - debugging

This time the actual program (pointer) ZBGTEST2 is in group with No. 35.No. 35 corresponds to our function group SAPLZDEBUG2.

39

© SAP 2009 /

Sharing Relationship - Examples/Exercises

Remember Watchpoint exercise 1:

Run transaction VA01 withRun transaction VA01 with order type = TA / sales organization = 0001 /distribution channel = 01 please use se80 to start debugging from the scratchlocal/global Watchpoint on VBAK-VDATU-->local watchpoint stops in SAPMV45Aglobal watchpoint stops in SAPFV45K

Is there sharing envolved ??

Use the debugger functionality : Display loaded / active programs and check if the mentioned programs share.

You will see that they share.N° Program in group with1 SAPMV45A3 SAPFV45K 1

40

© SAP 2009 /

Debugger 2 - Examples/Exercises

Optional: (If you have some spare time) Make yourself familiar with the expert display features in the debugger

System areasZDEBUGSYSTEMAREA

SharingZDEBUGTABLES (40B)

Check the behavior of the debugger when using the settings system (ZDEBUGSYSTEM)background task(ZDEBUGARFC)update (ZDEBUGUPDATE)

41

© SAP 2009 /

Summary

Now you are able to:Apply expert features of the ABAPDebugger in the analysis of

UpdateRFCExport to/ Import from MemoryData transfer to filesSystem exceptionsSharing relationships

42

© SAP 2009 /

Copyright 2009 SAP AGAll 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 construedas constituting an additional warrant.

advanced debugging

Documents