Parallel Execution of Procedures in the AMDP Debugger

This topic describes an issue concerning the parallel execution of procedures that can occur during debugging of standard AMDPs as well as during debugging of CDS table functions. In particular, you could take this issue into account while debugging table functions that are used in unions and joins.

Multithreading Issue When Debugging AMDPs

Depending on your chosen debugger settings and breakpoints, it is possible that only some of your procedures are executed in debug mode, while others are executed in optimized mode.

More on this: AMDP Debugger Settings

Procedures that run in optimized mode can potentially trigger parallel execution of called procedures. These parallel executions can then have an impact on debugging.

The following example demonstrates this kind of situation for AMDPs:

Procedure A calls procedure B multiple times.
Procedure A runs in optimized mode, while procedure B runs in debug mode. The source code of procedure B contains a breakpoint.
The multiple calls of the procedure B are executed in parallel threads at the same time.

The AMDP debugger then stops all parallel thread executions of procedure B, but only the first one is accessed by the debugger for the variable inspection and user commands.

After choosing Continue (F8) or Step-Over (F6), the first thread continues with the execution, and one of the other remaining threads is stopped for debugger access.

Caution

The main impacts on debugging are as follows:

It is not easy to identify which thread is currently being debugged.
As there are no thread IDs, they are not displayed in any particular sequence in the AMDP debugger.

Tip For the example above, it can be helpful if you create an additional breakpoint in the procedure A. Then, the debug mode would be enabled also in the calling procedure.

Multithreading Issue When Debugging Table Functions

The multithreading issue can also occur if a table function is called in parallel by a SQL statement, for example, due to a JOIN or UNION clause. In that case, it is not possible to solve the problem by creating an another breakpoint and the described multithreading issue is unavoidable!