ABAP Troubleshooting

1

ABAP Troubleshooting

Boris GebhardtErik SodtkeSAP AG

2

SAP AG 2003, TechED_Basel / ABAP257, Boris Gebhardt / 2

Warm Up

How can I analyze this runtime error?

Why is the performance of my program so poor?

Where does thismessage come from?

There are many different possibilities to be in trouble with ABAP programs:Hard errors (Runtime errors, abortion messages …)

Wrong program flow or behaviour

Poor performance.

But the programming language ABAP and the surrounding tools will not let you alone with the error.But a major problem is to choose the appropriate tool at the right time…

3


Tools for ABAP Programs - Agenda

static checks Syntax Check

Extended Program Check (SLIN) Code Inspector (SCI)

runtime checks

System log (SM21)

ABAP dump analysis (ST22)post mortem analysis

ABAP runtime analysis (SE30)

SQL Trace (ST05)

runtime analysis – traces

Dynpro Trace (ST20)

detailed runtime analysis ABAP Debugger

Coverage

Analyzer

Organisation of the tools:

Static checks during development and quality phaseDifferent tools analyse the ABAP code concerning possible runtime errors, screen consistency, possible performance killer …

Run time checks

Post mortem analysis:If hard errors occur during the run of a program – abortion messages, runtime errors, …,then the first approach is always to analyse the error and its surrounding, especially if you cannot reproduce the error.For instance, the runtime dump contains 20 pages of very precious information, which are often good enough to solve the error without any further debugging.The system log provides the surrounding of the error. What was the initial error of an error chain…?

Runtime analysis – traceThe error can be reproduced and now you want to get more details about the program without using the debugger.(The debugger often provides too detailed info, particularly if you are not familiar with the program)A normal ABAP program contains SQL statements, screens and – of course - the ABAP statements.For each part we provide very elaborated trace tools: SQL trace, dynpro trace and ABAP trace.

Detailed runtime analysisThe most detailed approach to find an error is the debugger. Here you can check each bit, but don’t use it as a default tool because the mass of info can hide the really important traces.

4


Tools for ABAP Programs - Overview

System log (SM21)

ABAP dump analysis (ST22)


SQL Trace (ST05) Dynpro Trace (ST20)

Static checks of ABAP programs – Quality management

Syntax More sophisticated checks like parameter match etc.

Runtime checks

Performance analysis

program flow find statements

Dumps check environment

of the error

Syntax Check Code Inspector / Extended program check

Screen processing

Debugger

Coverage

Analyzer

Organisation of the tools(II): error category approach

Which tools is suitable in which error situation?Most of the runtime tools cover several problem areas. The ABAP Trace is e.g. a very good tool to search performance lacks, but also for analysing the program flow.

5


Static Checks – Quality Management

Static checks Syntax Check

Extended Program Check (SLIN) Code Inspector

Avoid trouble shooting of difficult ABAP problems by intensive

static checks in the development phase!

1. Syntax Check – correct the syntax errors

2. Extended program check – make your program error / warning free

3. Code Inspector – analyze the performance, security and further hints

4. Check the runtime behavior of your programWith the Coverage Analyzer you can ensure,that you run through all parts of your program.

Coverage Analyzer

Sophisticated static program checks should be part of each development process.

Ensure a very high quality of your ABAP programs:

First the program should have no syntax errors.

The next step is to run an extended program check for this program. This includes more time consuming checks, which are not part of the syntax check like correct function calls w.r.t. the interface or finding unused variables, etc.

Even more tests are provided by the code inspector. Here you get, e.g., hints where you may have a not totally perfect select statements (performance!) or where you may encounter security problems.

Afterwards you must assure the correct runtime behaviour of the program. You may use the coverage analyser to check if all parts of your programs were covered by the test.

6


Static Checks: Extended Program Check

F1-helptests of each category

From the ABAP editor you can access the extended program check

/nslin

Extended program check (transaction SLIN)

You can decide which checks shall be done. Press F1 for each test family to get detailed information on the tests to be executed.

7


Static Checks: Extended Program Check

Get detailed info about the error and access directly the responsible source line.

The result of an extended program check is a table which displays the messages / warnings / errors for each test family.Errors and warning should be corrected by the developer. An error would be e.g. to call a function which does not exist.This will lead to a runtime error during program execution anyway.

From the overview table you get, via double click, to a detailed error description and from here you can directly access the source code to do your correction.

8


Static Checks: Code Inspection from the ABAP Editor

Code inspection from SE38:

The code inspector executes a default test set for the selected program.

ABAP Editor

Code inspector is available with WEB AS 6.10for R/3 >=46C a transport is available-> note 543359

The code inspector (transaction SCI) is a mass test framework which is delivered with WEB AS 6.10. ( for R/3 >=46C a transport is available -> note 543359)

You can define your own:program set (Which programs shall be checked?),

Test set (Which test shall be executed – you can even define your own checks)

From the ABAP editor you can access the code inspector with a default program set (the program which is currently in use of the ABAP editor) and a default test set. This global default test set has the name “default” and can be adapted to your requirements like any other test set.

The default test set contains the following tests:Performance checks (e.g. tuning of select statements)

Security checks (e.g. client depending INSERT/UPDATE….)

Extended program check

9


Static Checks/Code Inspector: Defining Check Runs

21

/nsci

3

The code inspector provides an open architecture for ABAP tests.1. Create a check variant: Specify which tests shall be executed.

2. Object set: Which ABAPs (programs, classes, …) shall be checked?

3. Inspection: Define an inspection which contains the relevant check variant (1) and the object set (2).

The inspection can now be executed online or in background. You can even make settings for a parallel run. (on several servers)

Some remarks to the object selection:You cannot collect SAP repository objects in your object set. Only customer objects are allowed.There is one exception. If you have changed a SAP program (e.g. because of a note), then you can use single code inspection from SE38 (-> slide 8) during the first week after the change.

Only in a development system code inspections are possible

If you check the flag ‘Save Selections only’ in the program set definition, then the programs will be extracted as soon as the inspection starts. Only the selection, not the programs are stored beforehand. This is a suitable technique if your program set will change before the inspection runs.

10


Static Checks/Code Inspector: Analyzing Results

Navigate to the source line

Search run (find sy-subrc) finished

The result contains all source lines found andall errors which occurred during searching.

Example: searching for a special string (e.g. the use of a special SY field)

The result list contains all found occurrences, and all errors which occurred during searching. You can navigate from an occurrence to the relevant source line.

If a run didn’t finish successfully, then you can restart the inspection from the point where the error occurred.(no rerun from scratch necessary)

11


Code Inspector – Tips & Tricks

Anonymous inspections

If persistent inspections results are not needed, you can createan anonymous inspection:

create an inspection with blank name

you can either use predefined object sets and check variants or define everything online

inspection results are not stored on the database

12


Static Checks: Code Inspector – Exercise

Exercise 1:

Use the code inspector to run the extended program check or syntax check for all our test programs.

They all start with ZTSTECHED02* .

The code inspector can be used to run the extended program check for all your programs to get an overview of the current quality level.

13


Coverage Analyzer

The Coverage Analyzer is a tool for monitoring the system-wideexecution of ABAP programs.

You can

monitor which programs and even which modules of a program were covered by a test

find program parts or complete programs which are never used andmay be obsolete.

find program parts that are executed very often and may benefit from code optimisation

Coverage Analyzer is available with WEB AS 6.10

The Coverage Analyzer stores which programs and even modules of programs where executed in a system and if any errors (dumps) occurred.

This allows you to ensure that all programs and even modules were covered by a test.

14


Coverage Analyzer

Make sure that the coverage analyzer is running properly

on your server before testing!

/nscov

SAP Easy Access

The coverage analyser is divided in the administration and the display part.

The administration covers:• Switching on /off the data collection

• You can specify the conditions, when a program shall get the flag “tested”. e.g. at least 1 time executed without any error.

• Reset the results for special programs to start a new test phase

• Define test groups and attach users to these groups. You can now display the results for these test groups.

• Monitor the data collection – to detect errors or problems (RFC connection …)

• Check the consistency and repair inconsistencies in the coverage analyser data. E.g between shared memory and the database.

15


Coverage Analyzer – Global View (QM)

Global view:Get the test coverage and number of errors for a development class or an author. This is a good tool for a quality manager who has to ensure professional testing and a good quality of a development project.You see the statistics since the last reset and the accumulated values.

16


Coverage Analyzer – Detail View

Check which modularization units of your programs were executed (covered) during a test.

For a developer is is more important to see not only the test coverage of e.g. a development class, but to go more into details and display the coverage of a special program or even of one module.

In this example function group WBABAP was covered 76.1% by your test. If you loot at the details, you see that e.g. the form BRANCH_TO_TYPE_ATTR hasn’t been executed – and therefore is not tested (red traffic light).

17


Tools for ABAP Programs (I)


Extended Program Check(SLIN) Code Inspector

runtime checks

System log (SM21)


post mortem analysis


SQL Trace (ST05)runtime analysis – traces

Dynpro Trace (ST20)


18


Post Mortem Error Analysis: System Log

SM37

ST22

/h

My batch job crashed after 7 hours.Which tool is a

good starting point?

The syslog is helpful if you encounter:• update terminations (SM13)

• job terminations (SM37)

• any kind of unknown errors

• If you encounter the dump SNAP_NO_NEW_ENTRY (no more dump can be written in the dump database table SNAP), then you can find the real error in the syslog

The syslog is very helpful if you want to check the general situation of the system:Which errors occur in the neighborhood of the real error? Which was the first error of an error chain?

Additionally the syslog is a good starting point for a deeper analysis.With the information about error kind/user/transaction/work process/… you can tackle more detailed trace files like the developer traces.(dev_w<n> files, accessible via transaction ST11)

19


Post Mortem Error Analysis: System Log– Remark

Keep in mind:

The normal (local) system log only shows log entries of the current

server !!Update or batch errors may occur only on special servers with update and batch work processes!

System messages are logged in a single circular file on a server. When this log file reaches the maximum allowable size, the system starts overwriting the file from the beginning.

Types:If the R/3 system runs on UNIX hosts, there are two types of logs:

Local: Each R/3 application server has a local log that contains messages generated by that server.

Central: Each application server also copies its local log entries to a central log.

You can always use “ALL remote logs” to get the system log of all servers.

Accuracy:Local log file: Always up to date

Central log file: There can be brief delays between when the system records a message in a local log and when the same message is written to the central log

Additional useful selectionsUser: Due to the number of logged information this will reduce the displayed list.

SAP process (Workprocess x, update process, etc. See F1-help for the field)

Problem classes

20


Post Mortem Error Analysis: System Log

Example 1: Batch job for user GEBHARDT failed

1st step: System Log (or Job Log: SM37)

Double-click for details

Time: When was the error recorded

TA: W1 and W5 means that the problem occurred in work process 1 and 5 (see transaction SM50). If the customer has more than 9 Dialog work processes, then we use characters to count them. (R/3 release < 4.6) -> WF = work process 15

Cl.: The client

Tcod: The transaction in which the problem occurred

MNo: Message number

Problem class (after double-clicking a line)K = Kernel messages

S = Status messages

T = Transaction messages

W = Warnings

X = Other types of messages

A ‘>’ sign in a text line means that this is a continuation line.

21


Post Mortem Analysis: Dump Analysis

2nd Step: Runtime Error analysis ST22 – select the relevant dump

Lock a dump to ensure that itwill not be deleted automatically

Get the date/time and user data from the system log and select the appropriate dumps in transaction st22.The following list contains the selected dumps.

Usually a periodic job deletes all dumps which are e.g. older than one week. To ensure that a dump will not be deleted you can explicitly lock it. (-> compare note 11838)

22


Dump Analysis

I got this dump during a batch run.It aborted after 7h.

It is very hard to debug this error.The dump file must be sufficient

for the analysis.

At the end of this chapter you will be able to extract all the valuable info from a short dump.

23


Dump Analysis – ST22

Dump overview: Press F6 in

the dump display

Which information is available in the dump display?

SAP BASIS < 46D

SAP BASIS >= 46D

The most valuable information are included in:

(3) Error analysis(4) How to correct the error

(5) System environment(6) User, transaction…

(7) Information on where termination occurred(8) Source code extract

(9) Contents of system fields(10) Chosen variables(11) Active calls / events

(12) Internal notes(13) Active calls in SAP kernel

24


Dump Analysis – Systematic Steps

1) Check the dump identification (e.g. CALL_FUNCTION_CONFLICT_TYPE)

2) Get the system environment (release, OS…)and user information (user, transaction…)

3) Read the error analysis and how to correct the error

4) Check the frequency of the dump and search for common info (server, transaction…)

5) Determine the affected programs/includes and the line number in the source code

6) Decide about further analysis(code analysis, field checks, call stack, …)

Some remarks on point 4). The other points are described in detail on the following slides.If you start transaction ST22 and select, e.g., all CALL_FUNCTION_CONFLICT_LEN dumps of the last days, then you get a list like this

Date Time Machine User Clt X Error ID

12.07.1999 11:47:01 pawdf025 FRANKM 000 C CALL_FUNCTI …12.07.1999 11:48:11 pawdf025 FRANKM 000 C CALL_FUNCTI …12.07.1999 11:51:17 pawdf025 FRANKM 000 C CALL_FUNCTI …

Please check if all dumps occur on one machine or only one user is involved …

25


Dump Analysis

(1) dump header, system environment, user & transactionDump header:

• Date and time of dump• Dump identification• Exception type (if runtime error is cacheable)

Collect the information regarding the System environmentSAP release, kernel release, patch level

Operating system, database type

Application server Is the error server-dependent, or do you find the same dump on other application servers, too?

Collect the information regarding the user and transactionClient, user, transactionThis will help to reproduce the problem

Get the screen number and the main program if the problem occurs depending on a screen

26


Dump Analysis

(2) Error analysis / How to correct the error

For many dumps, the information in sections „Error analysis“ and „How to correct the error“ is already sufficient to diagnose the reason for the dump.

The ‘Error analysis’ is one of the most valuable information sources:In this example you get the information that the function module BGTEST has a formal parameter MY_CARR. The imported field (SFLIGHT-CARRID) has a typenon-compatible to MY_CARR.

With the normal ABAP tools (SE38 / SE37 / extended program check [SLIN]) you can extract the cause of the error.

27


Dump Analysis

(3a) Information on where the error occurred / Source code extract

current program

current event (form, function, …)

main program.

Head of the program group

current include

and source line

Use transaction SE38 with the Include name to access the source.Knowing the number of the source line you can navigate directly to the faulty statement.There you can set a breakpoint for debugging or check the surrounding code.

Please be careful, sometimes the displayed source line is one statement behind the faulty one.

28


Function group

SAPLS_IMG_TOOL_5

current include

LSVIMF59

Dump Analysis

(3b) Information on where the error occurred / source code extract

main program.

Head of the program group

SAPLS_IMG_TOOL_5

Other programs

current event form VIM_BC_LANGU_ADD.

…

330 --> faulty source line

…

endform.

External performperform abc in program xyz.

External perform

29


Dump Analysis

(4) Contents of system fields / Chosen variables

Read the hex-code vertically

e.g. SPACE = 20

With WEB AS kernel 6.20, there are “Chosen variables” for every level of the ABAP call stack.

For information about system fields, please use F1-help (in SE38) with “ABAP System Fields”

In our example we learn from the system fields that the program BGTEST5 looped 1000 times until it failed. (sy-index = 1000).In a LOOP AT ITAB loop sy-tabix would be essential.If you have problems with memory consumption of large lists please have a look at sy-linno andsy-colno (line number, column number).

The chosen variables display some variables in the neighborhood of the faulty statement.The first line (blue) of the field contents displays the character representation of the underlying hex-value. Please read the hex-values vertically.In our case the interesting field P has the hex-value = 99 9C. Since P is a packed number and not a character field, the first (blue) line of field P shows only senseless characters. 99 9C is the hex-representation of the packed number 999.With WEB AS 6.10 you get a variable list for each stack level!

We deal with a packed number with length 2. This means it can comprise only 3 digits. Therefore we cannot exceed the number 999 and our program fails at the 1000th execution of the incrementing statement.

With WEB AS kernel 6.20, there is a “Chosen variables” entry for every level of the ABAP call stack.

30


Dump Analysis

(5) Active calls / events

event

program

include

The call stack shows you the flow of the program. With this information you can, e.g., display (via transaction SE38) the include LCATREF20, line 655 in order to check how the form CALL_DYNAMIC_FUNCTION_UNIT was called.

Please note that only the call stack, not a complete call history is available. If a function is called and then the runtime returns from this function and goes on, you will not find this function on the stack.

If you have, on the other hand, a CALL_FUNCTION_CONFLICT_TYPE, then the called function is not on top of the stack because the call itself failed.

31


Dump Analysis– Accessing the Debugger

If a runtime error occurs, you can jump directly into the ABAP Debugger and use the display features of this tool.

This is possible only as long as the dump is “fresh”.

After terminating the internal session (/n) the environment of the dump is deleted and you cannot access the debugger from ST22 any more.

32


Dump Analysis – Exercise (DUMP TABLE_INVALID_INDEX)

Exercise 2:

If you run report ZTSTECHED02_ST22 you get theDUMP TABLE_INVALID_INDEX.(Remember the introducing story.)

Please do not debug the program. Only analyzing the Dump text is allowed.Find out why this DUMP occurred and how the program should be corrected.

33


Dump Analysis – Solution: DUMP TABLE_INVALID_INDEX

Analyze the dump We learn from the dump:

Insert with Index 0 because sy-tabix = 0.

Sy-tabix = 0 because the read failed.

(target structure my_flight is empty!)

34


Runtime Analysis – Traces



runtime checks

System log (SM21)




SQL Trace (ST05)runtime analysis – traces

Dynpro Trace (ST20)


35


ABAP Runtime Analysis: Motivation

Where does this message come from?

I want to know the exact source line of the

message statement.

36


ABAP Runtime Analysis: Overview (I)

ABAP Runtime Analysis – Overview

Enables you to execute a performance and structure analysis of any transaction, program, or function module created with ABAP.The measurements are saved in performance data files.

Program flow hierarchy:

Only this tools is able to trace the flow of ABAP programs on statement level.Find the location of the statement you are interested inCompare the flow of the application in different clients / systemsFind USER EXITS, FIELD EXITS,CONVERSION EXITS, TA Variants.Trace the memory consumption of your application

Hit lists – performance measurements:

Determine the specific bottleneck area of the program (ABAP vs. SQL)Determine the SQL or ABAP statement causing the highest load

37


ABAP Runtime Analysis: Overview (II)

What is measured?

ABAP statements that are potentially expensive in terms of CPU time. The most significant of these are:

DB accesses: Select, Exec SQL, Modul. units: Module, CALL Function, CALL Screen, CALL Transaction,

CALL DialogInternal tables: Append, Collect, Sort, Read Table, Read DatasetFile handling: Transfer, Open DatasetOthers: EXPORT … TO …, IMPORT … FROM …, Rollback, …

SET PF-STATUS, SET TITLEBAR, MESSAGE, ASSIGN

How is it measured?During runtime analysis, the system measures the statements listed above.The system stores these measurements in a performance data file. (DIR_ATRA)You can evaluate the file (on the current server) immediately or at a later time. The system subtracts the CPU consumption needed for doing the measurement from the total CPU consumption.

ABAP Runtime Analysis trace file have the name AT<number> and are stored on the local application server in the directoryspecified in the profile parameter DIR_ATRA.

If ABAP Runtime Analysis has problems to read the filed and e.g. you get a runtime error using Se30 before the first screencomes up, then you may transfer (or delete) the AT… trace files on this server to another directory for later analysis.

38


ABAP Runtime Analysis: Start the ABAP Trace

Start the Runtime Analysis via:

Menu: System -> Utilities -> Runtime Analysis -> Execute

Transaction: /nSE30

Maintain the tracerestrictions in a variant

Insert the transaction, program or function you want to trace.

Or start the trace for a parallel session

39


ABAP Runtime Analysis: Variants – Trace Restrictions

Create your own restriction variant:

Press button “temporary variant”

Press button “Change”

Possible trace restrictions:

Program parts (Method nnn of Class CL_…)

Statements (e.g. with OPEN SQL – SELECT …)

Trace file / aggregationHierarchy is only available with “aggregation none” !!

With WEB AS 6.20 you can easily create a se30 variant with a new “Create Icon”. This Button will substitute the Button “temporary variant”

With aggregation the hierarchy is not available. For memory usage info in the hierarchy check the “With memory use” flag.

Program (parts) – “Particular units”This option allows you to switch on/off the ABAP trace during the running transaction. Especially, if the you are only interested in a special part of the transaction (e.g. between screen 3 and 4), then you should use “Particular units”.

Instruction for tracing “Particular units”: (trace program part between two screens)• Start SE30

• Switch on “Particular units” for your variant

• Start the tracing for your transaction. (“Execution” button)

• The trace will be started as soon as you prompt /ron (Trace on) in your transaction. With /roffthe trace is stopped. (Or you use the menu: System -> Utilities -> Runtime Analysis -> Switch On / Switch Off)

You can even use this technique in combination with the debugger. Set a breakpoint at the beginning of the interesting program part and at the end.If you stop at the first breakpoint, switch the trace on and at the second switch it off.

40


ABAP Runtime Analysis: Tracing a Transaction

Run your transaction

Step back to the runtime analysisYour trace file is now accessible.

Start the program / transaction via se30 with your variant. Step back to SE30 if the interesting part of the transaction is finished.You now see the new trace, which can be analysed.

If the trace file is not available, then please use the button “Other file…” to browse for your trace file.

If you got an error message when returning to SE30, which indicates that the measurement failed,then you may use the “File info” button to get the detailed error code. If you used a variant with active aggregation the please rerun your trace with

“Activation = NONE”.

41


ABAP Runtime Analysis: Tracing a Transaction – Hierarchy

Call hierarchy

Access the hierarchy (only available with a “no aggregation” variant) from the overview screen.

You get a list which represents the complete path through your application.

42


ABAP Runtime Analysis: Hierarchy – Features

Display filter

-> Which info of the trace file shall be displayed?

Default: Only application info is displayed.

For each trace line you can step to the relevant ABAP source line.

In the trace variant you specified already which statements and which parts of your application shall be traced.Additionally you can now filter which data you want to display.

Please notice that some display filters are switched on per default (e.g. no system programs).Therefore if you miss something, switch off all display filters and check your trace variant.

You can step from the trace directly to the relevant source line.

43


ABAP Runtime Analysis: Hierarchy

Stack level Allocated memory in BytesSwitch on “With memory use” in the trace variant to get this info!

The hierarchy list contains the following data:• Gross/net time (-> performance part of this chapter)

• Level: Stack level

• Call hierarchy: name of the statement / event.

• Program: current program / class

• Memory requirement: the current use of memory. The maximum values are marked with a red background colour.This feature is only available, if you switch on “With memory use” in the area duration/type of your trace variant.(default: switched off)

44


ABAP Runtime Analysis: Hierarchy – Exercise

Exercise 3

Run transaction ST22 (Runtime Error Analysis) and search for dumps for user XXX.You get the error message: “None of the selected short dumps exist”(SN/404).

Use SE30 to find the source position of this message statement.Find out in which form the message is launched (use the stack level in the hierarchy list)

45


ABAP Runtime Analysis: Trace a Parallel Process (I)

The batch job is running and always reading DB table SFLIGHT.

What is this program doing?

With Basis release >=46B you can use Runtime analysis to trace program which run in a parallel session.

46


ABAP Runtime Analysis: Trace a Parallel Process (II)

Switch on/ off the trace for the marked process

Ensure that you run SE30 on the same server as the running batch job!

If you used a 46D kernel with patch level >=1413 (or 6.10 kernel patch level >=427), then you can switch on the ABAP trace for idle processes as well (note 586940)

You must create your trace variant for the parallel trace as well. (no aggregation to get the hierarchy…)

Stop the trace after a short tracing time in order to avoid reaching the trace file quota! (profile parameter abap/atrasizequota)

47


ABAP Runtime Analysis: Trace a Parallel Process (III)

Analyze the trace file

Looks like an endless loop!

48


ABAP Runtime Analysis: Performance Problems

Why is the performance of my program so poor?

ABAP Runtime Analysis is the best starting point for an ABAP performance analysis

After the hierarchy we want to use ABAP Runtime analysis to analyse performance problems.

49


ABAP Runtime Analysis: Performance Problems

Strategy:Restrict the trace file as much as possible (-> Variant). Especially for long running programs.Otherwise the file quota will be exceeded quickly.

Start with full or “by call” aggregation (only hit list available)

Restrict the statements – e.g. only modules (functions, forms, methods…)

Restrict the analysis in a second trace to the performance killing modules

Trace only a part of the transaction with the restriction “Particular units”

Variant – area Duration / typeaggregation Full: full aggregation for the selected statements

aggregation By call: if the source position differs -> no aggregation

None: no aggregation at all.

Profile parameter abap/atrasizequota and your variant settings limit the maximum trace file size

50


ABAP Runtime Analysis: Demo

Demo

51


ABAP Runtime Analysis: Performance Problems – Overview

With full aggregation only the hit list is available.

1. Distribution of the execution time:

ABAP (all ABAPs except OPEN SQL)

Database (Open and native SQL)

System (implicit program generation, loading of programs, …)

Reliability of the execution times on machines running with more then one processor:

The numbers represent not an exact measurement. But you get a goodimpression which parts of the programs consume most of the time.

To get reliable results you should execute the measurement several times.

The overview of the runtime evaluation shows if the performance killer must be searched in expensive selects (Database) or perhaps not perfect internal table handling (ABAP). For SELECTs a switch to the SQL trace (ST05) produces more detailed info concerning tuning (which index was used …).

In our demo example the overwhelming part of the execution part is spent on database operations.

52


ABAP Runtime Analysis: Performance Problems – Hit List I

Gross time

Time consumed in, e.g., a function. This includes the execution time of all modules or other program parts which were traced and which were called from inside.

Net time

= Gross time minus traced program parts which were called inside.E.g. the execution time of the FETCH T100 in FORM MSG_NR is subtracted from the gross time to get the net time.

Sort the list by net time to identify the performance killer!

Filter variant: Only form MSG_NR – default statements – aggregation by call

Filter variant: all parts of the program – only modules – aggregation by call

First run: We use the trace restriction variant:• Program parts: no restriction

• Statements: only modules

• Duration / type: aggregation by call.

The hit list is sorted by net time: We get the most time consuming modules (here forms).FORM MSG_NR consumes ~ 39% of the total run time.So this form seems to contain some “expensive” statements and it seems to be worthwhile to go into details concerning this form.

Second run: We use the trace restriction variant• Program parts: only form MSG_NR

• Statements: default

• Duration / type: aggregation by call.

We traced only form MSG_NR, but now we trace all statements. The hit list is sorted by net time again and we see that a SELECT … FROM T100 (Fetch) is the major time consumer in FORM MSG_NR.

53


ABAP Runtime Analysis: Performance Problems – Hit List II

Use SQL trace for detailed analysisof SQL statements.

From the Fetch line we can directly navigate to the source line to check why this SELECT is so time consuming.In this case it is obvious. For counting DB entries the developer should use aggregations like COUNT(*), but if it is not so easy, then a SQL trace (ST05) for this single statement would be the next step.(missing index etc.)

54


ABAP Runtime Analysis: Exercises

Exercise 4a

Run the SE30 trace for the 2nd performance killing formMAX_MSGNR (program: ZTSTECHED02_SE30_PERF) as well.

Try to understand why the performance of this form is so poor.

Compare this with the trace of the same form MAX_MSGNR in program ZTSTECHED02_SE30_PERF_OPT.

Exercise 4b (optional)

Run the SE30 trace for the form NUMBER_OF_MESS (program: ZTSTECHED02_SE30_PERF) as well.(Switch on the internal-table statements in your restriction variant.)

Compare this with the trace of the same form NUMBER_OF_MESS in programZTSTECHED02_SE30_PERF_OPT.

Why is the performance of the LOOP in the optimized program so much better?

55


ABAP Runtime Analysis: Performance Problems – Special Hit Lists

no aggregation -> all hit lists and the hierarchy are available

Group hit listDB table hit listClass hit listInstance hit listMethod hit listEvent hit listInternal table hit list(only if internal-table statements are included in your variant!)

DB table hit list

If you use no aggregation, you can choose within a variety of hit lists.Most important is the DB hit list. Here you can see with one glance which DB table are accessed how often and how much execution time is attached to them.Additionally you get some info from the DDIC, concerning the Table type (TRANSP, POOL, …) and the buffering.

The other hit lists provide info which internal table or class … consumed most of the time.

56


ABAP Runtime Analysis: Summary

ABAP Trace (Call hierarchy)Trace on ABAP statement level (find MESSAGE …)

Restrict the trace to the ABAPs you are interested in.(Explicitly by naming the programs or dynamically with “particular units”.)

Trace the memory consumption of the transaction(trace variant with switched on “With memory use”)

Performance Trace (Hit lists)

Restrict the trace in the first run to the modules and use aggregation inyour trace variant . In the second run you can specialize the trace on themajor performance killer.

Check the global hit list for the major performance killer. (Sort by net time)

If you use “no aggregation” then you may analyze the detailed hit lists forDB tables, ABAP Objects,…

57


Screen Trace

Start screen trace via transaction: ST20

With SAP Basis release 46B, transaction ST20 (screen trace) is available to analyse Batch Input or all other errors which are connected with screen handling (field transport, screen sequence, resize, F1, F4 help)

In older releases you can use the report RSTRC000 to look at the screen trace. (notes 0508748 or 0087150).

58


Dynpro Trace – Available Info

Trace level 2 Trace level 3Trace level 1

severe errors only focusOK-Codedata received flag

Load/generate dynproPBO,PAI,DCI,DCO stepsapplication/system modulesdark processingmain screen, subscreen

set screen, leave screencall screen, skip screencall dialog, call transactionsubmit

step loop processing

messages

send/receive data from SAPGUI

field contents– conversion exits– field exits– global fields

set/get parametermodify screen

batch input processing

screen resizescreen compressionsubscreen tree

59


Runtime Analysis – Debugger



runtime checks

System log (SM21)




SQL Trace (ST05)

runtime analysis – traces

Dynpro Trace (ST20)


60


Debugger: Start an ABAP with the Debugger

ABAP-Report

SE38 Button “Debugging”

The report will be started directly in debugging mode.

If you insert /h in the OK-field, you will not debug RSPARAM but the editor (SE38) itself.

61



Function module

SE37Button “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, obtain the parameters for the function interface and try to reproduce the error in an isolated test (SE37)

62


Debugger: SE37 – Demo

Function module Z_DEBUG_SE37

SE37Button “Single Test”.

Where is the output ??

My_export should be 123 ??

1 function z_debug_se37.

2 *"-----------------------------3 *"*"Lokale Schnittstelle: 4 *" IMPORTING 5 *" VALUE(MY_IMPORT) 6 *" EXPORTING 7 *" VALUE(MY_EXPORT) 8 *"-----------------------------9

10 my_export = 123. 11 write: / my_import. 12 endfunction. 13

If the type of the export parameter is not specified in the test environment of SE37, a default field with type char(200) will be generated.

By the way, if you call this function from another program without specifying the import parameter:

call function 'Z_DEBUG_SE37'

exporting my_import = 'ABC'.

Then my_export in the function will have the default type char(4).

If you specify the parameter, the system will generate a field which has the same type:

data int type i. call function 'Z_DEBUG_SE37'

exporting my_import = 'ABC'

importing

my_export = int .

my_export has type I in the function module.

63



You can start a transaction in debug mode from the transaction maintenance. (SE93)

The transaction will be started directly in debugging mode.

With R/3 Release < 4.6A:• SE80, button “Edit”

• Fill in transaction (e.g. VA01)

• Test / Execute (F8)

• Select radio button “Debugging”

Or much faster (Enjoy release ≥ 4.6A):• Transaction SE93

• Fill in your transaction

• Menu path: Transaction Code -> Test -> Debugging

64


Debugger: Start Debugging for a Running ABAP

For a transaction:OK-Code field in the transaction: /h (switch on debugging)/hs (system debugging)

For a batch job or long running programSM50:

Select the program to be debuggedMenu: 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 have the problem

• Start to debug e.g. a batch report when you think the problem comes up (e.g. high memory consumption)

• For debugging basis transactions usually the system debugging will be needed (/hs)

A batch job will not stop if a breakpoint is reached. Even for the statement BREAK-POINT only a sys log entry (Breakpoint reached …) is generated.

But you can access the batch process via SM50 and then you can use all features of the debuggerYou can set dynamic/static breakpoints, display or change fields …

To debug a batch job at a specific line of your code you may introduce an endless loop in the code.(I = 1. WHILE I=1. ENDWHILE)Then you use sm50 to debug the batch process and change the condition to leave the endless loop…

65


Debugger: Job Debugging – Hidden Feature

In the job overview(SM37) you can debugeach job with the ok-code JDBG. But please keep in mind:This is like a restart of the job.-> All possible updates will be executed !

If you have to analyze an aborted job, then you can restart the job in debug mode. This is a “background simulation” which actually runs in a dialog work process to allow debugging.But e.g. the spooling is done and sy-batch =‘X’. So from the ABAP perspective the program runs in a background environment.

Instructions:Run SM37

Mark the job you want to restart in debug mode

Prompt jdbg in the ok code

You reached the debugger

But please keep in mind, this is no simulation. All updates, deletes or whatever else is done in this job will be executed !

66


Debugger: Start Debugging with a Shortcut

Create the shortcut with a SAPGUI higher than 4.5A

Select “SystemCommand” from the pull-down menu

Insert the debug command (/h or /hs)

Generate Shortcut on the desktop

Confirm with OK and the shortcut will be placed on the desktop

67


Debugger: Start Debugging with a Shortcut

Drag the shortcut directly on the screen where you want to startdebugging

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 the ABAP of a popup directly.

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

68


Debugger: Navigation in the Source Code

Increase program section size

Step to current statement

Scroll source code

Control buttons

F6 Execute

F8 Continue

F7 Return

F5 Single Step

(Beginning with 4.5: Continue until cursor)

Navigate through the coding:Single step: one single statement will be processed

(functions, forms, etc. will be entered)

Execute: one single statement will be processed (functions, forms, etc. are treated as one command)

Return: all remaining statements of the current routine will be processeduntil its end is reached

Continue: all remaining statements will be processed until the next breakpoint orwatchpoint,

or the current cursor position, or the end of the program is reached

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 and the DECIMALS settings influences only the output.

69


Debugger: Navigation from the Debugger to the Output

Show next list 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 the 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)

70


Debugger: Navigation using the Active Call Stack

Double-click this line in order to navigate to this function on 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 during the program flow.The switching itself is triggered by double-clicking on the desired level.

Please keep always in mind that you only see the pure call hierarchy. If the program jumped to another routine and returned you are not able to find a trace in the call stack.(For this purpose use ABAP Trace [SE30].)

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

71


Debugger: Display Data in the Debugger

(2)

Double-click

(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 on any field name; this will lead into the detailed field view (3) or, if the field name specifies a structured field, you will be switched into the structured field view (2).

A double click onto any field in the structured field view or table view will lead you into the detailed view of the simple field.(3)

You can also access the field directly:Enter: sflight-paymentsum.

You can access the different views also from the menu:

Goto -> Display data object ->

Single field (Ctrl + F2)

Structured field (Ctrl + F3)

Internal table (Ctrl + F4)

72


Debugger: Display Data in the Debugger

(1)

Double-click

(2)

Double-click

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

A double click onto any field in the table view will lead you into the detailed view of the field. (Like shown in the slide above, into an internal table (3))

You can also access the field directly:Enter: my_struc-itab2[].([] means table contents / itab2 might be only the header line of the table)

Example:my_struc-itab2[2]-mandt will display the field mandt of the second line of the internal table my_struc-itab2.

If you have an internal table with a header line:Data: itab like sflight occurs 0 with header line.

Then itab represents the header line and itab[] the body of the table.

73


Debugger: Manipulation of Variables

Each value displayed can be changed as well edit the value (1)click the pencil icon afterwards (2)

(1) edit

(2) change0

If you enter a variable name in the variable area of the debugger, you will be able to see the contents of the variable (and scroll if needed). When using structures or tables instead of “normal” variables the system will display the work area of the variable. Entering a variable can also be done by double-clicking on a variable in the coding.

It is also possible to change the contents of a variable by overtyping the contents and pressing the pencil. This change will be documented in the SYSLOG and you need a special authority. (S_DEVELOP/DEBUG/01)

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

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

74


Debugger: Manipulation of Internal Tables

Columns

Delete the title if you want to hide the column (This does not delete the column.)

Scroll Buttons for switching between the columns

Choose the table operation you want to perform

Header line (WA)

Search Buttons for searching in the internal table

In order to manipulate internal tables you can either use the button “Table” or double-click on the internal table. The system will switch to the table view screen. Within this view you can:

scroll horizontally and vertically through the table

hide columns by deleting the column title in the column line

shift column by entering a specific column name instead of a displayed column name(e.g. replace VONTG by PERDLY and you will see PERDLY as first column)This is merely a display functionality. Your changes have no effect on the internal table.

search (R/3 Release > 4.0B) through the lines by using the search button in the application toolbar. Positioning the cursor on a certain line uses the line contents as search pattern.The normal search button (in the standard toolbar) searches in the source code.

insert, modify, delete an entry Please keep in mind that the entry is only changed column by column (except with the delete button)

If you want to insert a line, 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

75


Debugger: Exercise (Change Variables)

Exercise

Get comfortable with the display and change features of internal tables. Use itab[] in ZTSTECHED02_DEBUG_DISPLAY, form FILL_ITAB(after the SELECT) as an example.

Display the list output after each WRITE statement.(You may set a breakpoint at the statement WRITE to access the first WRITE – Menu: Breakpoint -> Breakpoint AT -> Statement)

Optional task: Start ZTSTECHED02_SE30_JOB via transaction SA38 as a background job. (Start time: immediately). You remember this was the program which never ends and which we traced with SE30.Now we would like to debug it.Step to transaction SM50 find the batch process where the program is running. Mark this line and jump into the debugger. (Menu: Program/Mode ->Program -> debugging).Change the variable I in the debugger so that the program can finish.Verify in sm50 that the program finished and our program no longer occupies the batch process.

76


Debugger: Display ABAP Objects

Double-click

The object reference grid1 contains an instance of class CL_GUI_ALV_GRID.Double click on this instance to get the contents of this object.

You may use the filter to display e.g. the private attributes as well

You can display all attributes of your ABAP objects. To see the private/protected attributes use the filter icon.

If you display a reference, you get the referenced instance namenr<class_name> (e.g. 69<CL_GUI_ALV_GRID>). Double-click on the instance displays the content of this instance.

With Goto -> System -> Find references you can display all references that point to a special instance of a class!

77


Debugger: Display ABAP Object Events

Display the events of grid1.(CL_GUI_ALV_GRID)

Get the handling object of the grid1 events (Set by SET HANDLER…)

The button event for an instance displays all events of this class and the attached event handler.

78


Debugger: Static Breakpoints

Set breakpoints directly in the editor (SE38)position the cursor in a valid line press the stop iconthe line will be marked (Rel. < 46A: stop icon in the source code)

Set breakpoints directly in the debuggerposition cursor in a valid line and double-clickthe stop icon will appear in front of the line

1. hard coded breakpoints:BREAK-POINT.BREAK JACK. (Hans is the user name).The first leads to a stop for all user which are in a dialog session (on all servers).The second is a macro, which is defined in Table TRMAC.This macro is the short form of:IF sy-uname = ‘JACK'.

BREAK-POINT.ENDIF.

2. If you use the “normal breakpoint” mechanism in the editor (stop icon), these breakpoints are only effective for your user and your current logon session!(You will not realize this breakpoint on a different server!)

3. If you set a breakpoint in the debugger, this breakpoint is only effective for the current debug session. If you save the breakpoints, they behave like editor breakpoints (->2)

Unfortunately it’s not possible to set a 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)

79


Debugger: Dynamic Breakpoints

Choose the criteria you want to set a breakpoint at

You may want to save the breakpoints for the next debugging session

You can activateand deactivatebreakpoints temporarily

Set breakpoint at:Statement, e.g. select. You will find breakpoints at all select and (open/fetch) cursor-statements

Event/Subroutine: at, e.g., start-of-selection (event) or at a form of the current program.If you use a release > 4.0B, you can specify the main program of the form explicitly

Function module: Insert the name of 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, you maymiss an occurring dump. If you set breakpoints at system exception, the debugger will stop at the statement where the skipped dump occurred.

Deactivate / Activate breakpointsThat’s not the same as deleting and setting breakpoints.If you deactivate a breakpoint, 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, e.g., you can deactivate the breakpoints, then fill some screens, and then 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.

80


Debugger: Possible Problems with Breakpoints

Please save the breakpoints in the debugger if you want to usethem in a later debugging session

If you use dynamic breakpoints (breakpoint at … statement) pleasesave these breakpoints to ensure that they are available in all internal sessions.

Please restart the program after setting a static breakpoint inSE38. A running program will not see the new breakpoints.

The saved breakpoints are only available in yourcurrent logon session. Other users or you in another sessionwill not realize the breakpoints.

81


Debugger: 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 not stop before 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 runtime a dump occurs at an INSERT statement, which complains about a too big an internal table and a lack of memory.Now you have the problem to debug the program.You place a breakpoint at the proper INSERT statement, but unfortunately the INSERT statement is executed thousands of times.Now you can use the Count-technique.Set the count-field to, e.g., 1000 and execute. If you get the dump, decrease the value to 500, then 250, … With this technique you can quickly detect the exact moment when the error occurs and start debugging there.

82


Debugger: Watchpoints

If you set a watchpoint on the field matnr (matnr = '1234'), the debugger stops as soon as matnr contains the value'1234'.

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

Matnr = 0000

Watchpoint: Matnr = 1234

Matnr = 0120 Matnr = 1234

Program flow

Watchpoints are very dynamic breakpoints.You can specify a field that should be monitored and you can specify a stop condition.

The system will inspect the memory address that is connected to the field name and will compare the value in this memory address according to the condition given by you.As soon as the condition and the current value “match”, the debugger stops.

83


In the view “Watchpoints” you can check the list of active watchpointscreate watchpointsspecify the logical operator between the watchpoints to stop either when all specified conditions are true or at least one ofthem

Debugger: Creation of Watchpoints

Create

change or delete watchpoints

If you wish to stop the program depending on the contents of a variable, you have to use a watchpoint.

Within the watchpoint you can specify the relational condition under which the system should stop (<, >, <>, <=. >=). Even the comparison with another variable (rather than a given value) is possible

If you create more than one watchpoint, you can link them together with AND or OR.

Local and global watchpoints:The debugger always looks at the memory address of the watchpoint-field.Some special variables and fields are shared between programs. (e.g TABLES, COMMON PART, SY-fields)This means two program look at the same memory address.If you use local watchpoints, the debugger checks not only if the contents of the memory address has changed, but compares also the actual program with thewatchpoint-program.If you use global watchpoints, the debugger will always stop if the memory contents change, independent of the program.

84


Debugger: Exercise

Run transaction SE09:Where does the pre-set USER = GEBHARDT come from?

1. Get the ABAP field name(TRDYSE01CM-USERNAME)

2. Start SE09 in debug mode (SE93) and set a watchpoint on the field.

3. You stop at the following lines:

CALL FUNCTION 'TRINT_READ_USER_CUSTOMIZING'

IMPORTING

es_settings = ls_settings.

CLEAR: trdyse01cm.

MOVE-CORRESPONDING ls_settings TO trdyse01cm.

4. Set a breakpoint at the preceding function and find out where and how es_settings is filled

85


Demo

Demo

Demo: watchpoint on a table header. (report ZTSTECHED02_DEBUG_ITAB)

Each internal table has a header which contains administration data like number of lines.If, e.g., someone deletes lines or appends lines, then this header is updated. It is possible to set a watchpoint on the table header. This is very helpful if you want, e.g., find the source line where an internal-table line is deleted. But keep in mind that modifications of the contents in a line have normally no effect on the table header.There is some more info stored in the table header (like the loop counter); therefore don't be too astonished if the program stops, e.g., at a LOOP statement.

Watchpoints on table headers in different releases:

< 40B itab-*sys* 40B itab[]45 itab[]+0(128)since 46 *itab[] (header is only filled when table is not initial!)

Since release 46 the table header is no longer stored directly in the addressable memory. Only a table reference (8bytes) remains in the memory addressable by the user. This table reference is a pointer which points to the header information. The table reference can be displayed by &itab[].(The same syntax */& is used for object, string and data references.)

86


Debugger: Settings

Menu: Settings ->

Display and change all

Be careful: Some settings are not displayed in the menu “Settings”.To get the full settings information choose Settings -> Display and change all (< 4.5A: Settings -> Display)

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

87


Debugger: Settings – System Debugging

System programs are outlined by blue color in the call stack.

System programs are skipped during debugging if you don’t use system debugging.

System Debugging on/off (/hs)

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, check if this function is part of a function group with status S (System program).This “effect” can be eliminated by System Debugging

System Debugging is necessary if you want to debug:– variants– selection screens– logical databases– the update process– batch processing…

With Release < 4.5A the system modules are not visible in the call stack if you use normal debugging.

88


Debugger – Settings – Update Debugging

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 in Update task then this function is not called instantly but merely its name and the interface data is stored in database tables(VBMOD /VBDATA)

If a COMMIT WORK is reached then the stored function modules which are linked to this LUW will be read from the database and executed in a free update workprozess.

89


Debugger – Settings – Update Debugging

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

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.

90


Debugger: Settings – Update Debugging / ARFC

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

In background task: Lock Release onYou can lock the sending of an asynchronous 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, you will find this function after the COMMIT WORK in transaction SM58.

If you use the normal asynchronous update, after a COMMIT WORK the update work will be performed by another work process (update work process). Therefore the debugger can’t debug the update procedure and will stop after the COMMIT WORK.If you switch on Update debugging, after the COMMIT WORK the update is executed in YOUR process and therefore the debugging can go on.

If you have to deal with aborted updates, then you can analyze them in transaction SM13. There you can restart, test or even debug thefailed update modules.

91


Debugger: Monitor Memory Consumption

Your process alone allocated ztta/roll_area + EM + HEAP~ 270 MB.

How can I find the major memory consumer of the greedy program?

Programs often consume much memory to build up big internal tables.If, at the next APPEND, the system resources are exhausted, the program will fail with, e.g., TSV_TNEW_PAGE_ALLOC_FAILED

The resulting dump will show that the APPEND (e.g.) was the last command. The system field sy-tabix will show the number of lines appended.

In the section “How to correct the error” you will find the amount of memory which was allocated at that moment. To get an overview you must sum up ROLL, EM and Heap. The Roll memory is the sum of all Roll memories of all users. But the EM and Heap figures correspond to your process. (Therefore, if another process also allocates much memory, then your process will abort before it reaches the parameter limits.)

Unfortunately the information in the section “internal tables” is not really useful because we delete some internal tables to get some memory for the dump output

Transation ST02 is very useful to analyze memory problems.E.g. Press “Detailed Analysis Menu” and then the Button “SAP Memory”.Current Parameters -> Get all memory parameters

If the Extended memory is exhausted, the Workprocess switches to PRIV mode. This means this process is now exclusively locked for this user. No one else can use this process. This event is stored in the dump as well. Part “Error Analysis”:Error text……… "Warning: EM-Memory exhausted: Workprocess gets PRIV "

92


Debugger: Monitor Memory Consumption Release > 45B

If you are able to debug the memory consuming program, you can use the ITAB-TOP25 system area to find the biggest internal table.

The columns ‘alloc. Netto’ and Used netto’ differ because we always allocate a certain amount, then use this up for e.g. several appends, and then we allocate fresh memory.

93


Debugger: Monitor Memory Consumption Release > 46D – Memory Inspector

With Release > 4.6D it is possible to display a ranked list of the most important memory consumers.This includes all loaded programs and all possible data types. (Internal tables, ABAP Objects, …)This feature allows us to see with a glance which fields hold most of the memory.

With WEB AS 6.40 the memory inspector is delivered. This is a tool which is integrated in the debugger and provides a standalone framework to compare and analyze memory snapshots. This functionality will be available in the WEB AS 6.20 at the end of the year.(note 606368)

94


Debugger: Outlook - New ABAP Debugger

Main features of the new debugger :

Standard debugger features (stack, variables, break points…)

Sophisticated navigation between ABAP data structures

Layout can be customized freely

New tools can be plugged in easily

Desktops for different views (standard, tables, user defined …)

History + undo functionality

Tools can be instantiated 4 times -> e.g. compare 4 internal tables

95


Q&A

Questions?

96


Please complete your session evaluation anddrop it in the box on your way out.

Feedback

Thank You !

The SAP TechEd ’03 Basel Team

97


No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® are registered trademarks of Microsoft Corporation.

IBM®, DB2®, DB2 Universal Database, OS/2®, Parallel Sysplex®, MVS/ESA, AIX®, S/390®, AS/400®, OS/390®, OS/400®, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere®, Netfinity®, Tivoli®, Informix and Informix® Dynamic ServerTM are trademarks of IBM Corporation in USA and/or other countries.

ORACLE® is a registered trademark of ORACLE Corporation.

UNIX®, X/Open®, OSF/1®, and Motif® are registered trademarks of the Open Group.

Citrix®, the Citrix logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®, VideoFrame®, MultiWin® and other Citrix product names referenced herein are trademarks of Citrix Systems, Inc.

HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.

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.

MarketSet and Enterprise Buyer are jointly owned trademarks of SAP AG and Commerce One.

SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies.

Copyright 2003 SAP AG. All Rights Reserved

ABAP Troubleshooting

Documents

Transcript of ABAP Troubleshooting