Upload
nhillier1
View
46
Download
4
Embed Size (px)
DESCRIPTION
Advanced Debugging
Citation preview
1
Analyse Problem - Using ABAP DebuggerAdvanced Debugging
Active Global SupportMarch 2009
2
© SAP 2009 / Page 2
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 / Page 3
Unit Objectives
This unit will prepare you to perform the following tasks: Use advanced debugger features for problem analysis
4
© SAP 2009 / Page 4
Debugger 2 - Expert Features of the Debugger
How do the ABAP gurus extract all these info from the debugger
5
© SAP 2009 / Page 5
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 / Page 6
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 / Page 7
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 / Page 8
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 / Page 9
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 / Page 10
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 / Page 11
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 / Page 12
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 / Page 13
Exercise and Demo - Settings
Demo: Update Debugging (ZDEBUGUPDATE)Demonstrate the Debug behavior with switched on and off Update debugging .
14
© SAP 2009 / Page 14
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
Field 1 Field 2 Field 3 Field 4
ARFCSSTATE ARFCSDATA
Field 1 Field 2 Field 3 Field 4
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 / Page 15
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 / Page 16
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 / Page 17
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 / Page 18
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 / Page 19
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 / Page 20
Expert Display Features
Doubleclick
Show Detailed Release Info
You can get a subset of this information via SM51/Release notes or Menu:
System -> Status
21
© SAP 2009 / Page 21
...
DATA c(20) TYPE c VALUE 'Debugger session'.
SET PARAMETER ID 'ABC' FIELD c.
Expert Display Features
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 / Page 22
Expert Display Features
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 / Page 23
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.
Expert Display Features
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 / Page 24
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 / Page 25
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 / Page 26
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 / Page 27
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 / Page 28
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 / Page 29
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 / Page 30
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 / Page 31
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 / Page 32
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 / Page 33
Sharing Relationship
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'.
PERFORM xyz(zbgtest2).
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 / Page 34
Memory
Prg1Prg1 = XX
Prg3Prg2
Prg2 = AA
Sharing Relationship
Active programs - sharing tables
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 / Page 35
Sharing Relationship
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 / Page 36
Sharing Relationship
Active programs - sharing tables
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'.
PERFORM xyz(zbgtest2).
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 / Page 37
Sharing Relationship
Active programs - sharing tables
Program3Local fields (DATA:)
Tables / Common part Form ABCMemory
Program 2function x
PERFORM ABC (PROGRAM3)
Program 1
PERFORM ABC (PROGRAM3)
Call function x
Prg1Prg1 = LH
Prg3
Prg2Prg2 = XX
38
© SAP 2009 / Page 38
Sharing Relationship
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 / Page 39
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 / Page 40
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 / Page 41
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 / Page 42
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.