SAP system behavior while debugging

In one of my previous posts I stated several possibilities how to start ABAP debugger tool. Here comes some debugging specialties discussed.

Debugging is often activity of skilled users or key users and I don’t know a lot of consultants who can avoid usage of debugging as well. Several possibilities are in place: remote debugging; tRFC/ /qRFC/bgRFC debugging; HTTP/external debugging etc. Normally we debug while logged in SAP GUI in SAP system. Basically you can switch processing of any transaction or report to debug mode via entering /h code to transaction field of SAP GUI. There are some other possibilities how to enter debug mode for e.g. job – this is possible via TA SM37 -> menu Job -> “Capture: active job” etc. SAP system based on NetWeaver ABAP stack application server has special functionality dedicated to debugging. A work process which is processing your task is set into a DEBUG mode. Debugging in general does requesting a huge memory consumption and system resources as well. This means that system is moving data to its extended memory in PRIV mode. In this mode normal request being processed by other work processes are located in local memory instead of extended. Extended memory is occupied by data for debugging user exclusively. However this cannot persist in system for a long time. So since you are not active in debugging session for some time system is canceling whole debugging with following messages:

Transaction from "PRIV" session reset after timeout (Message no. 14048)

Transaction from "DEBUG" mode (after timeout) reset (Message no. 14056)

From basis point of view for production system there should not be a necessity to adjust profile parameters in order to allow debugging for a long time and for a so much users. If you wish to avoid this message anyway or you want to make debugging more comfortable on development or test system you need to consider following profile parameters:

• rdisp/max_priv_time # Standard value: 600
• rdisp/wppriv_max_no # Standard value: MAX(1, Anzahl Dialog-WPs)
• rdisp/max_debug_lazy_time # Standard value: 600

Other very common obstacle is that there is not debugging possible at the moment; you can experience it while a system is issuing message like:

You cannot debug ABAP programs at this time

While there are a few more users doing debugging in system other than you; you can experience following message:

Max. number of debugging mode users reached (Message no. 14111)

In this case you need to check out entry in table T000-CCATEGORY. This field is describing a role of client that you are logged in. If there is a value of P it is a production system/client. In such a clients number of work processes that can change to debug mode is limited to half of the DIALOG processes in system. Therefore setup number of dialog processes accordingly.

If system is running out of memory and it cannot allocate enough memory for data processes in your transaction you may get message like:

Memory low. Leave the transaction before taking a break!

From user’s point of view you really need to at least restart transaction or better to log off and on to system. Basis team would need to re-setup a dialog timeout and/or work process timeout of profile parameters, memory parameters, increase physical of machine, etc.

BTW: Notice that ABAP debugger is completely written in C programming language and not in ABAP. On other world of JAVA stack – in NetWeaver Developer Studio debugging is completely different but this is another story…