Skip to Content
Author's profile photo Former Member

ABAP Breakpoints and System Macros

All ABAP developers should know that when dealing with (most) online processes we can use breakpoints to interrupt the execution of a program at runtime, taking us into the ABAP debugger. Broadly speaking, breakpoints are in one of two camps:

    • Hard breakpoints set by coding the breakpoint into the ABAP logic itself.

Hardcoded Breakpoints

The BREAK macro

Notice from the code snippet above that the BREAK keyword is in lowercase, even though all my other keywords are in uppercase (thanks to pretty printer)? This is because BREAK is not actually a keyword but rather a special macro defined in a configuration table that hails back to the R/2 days: TRMAC.


This form of macro works very similar to macro’s that you can define in your program using DEFINE / END-OF-DEFINITION, except that by being defined in table TRMAC they are automatically accessible from all ABAP programs. Notice that the BREAK macro expects one parameter &1, which will be placed within quotes to allow the character string comparison. So when I write in my ABAP program:

break bardens.

I am actually using macro shorthand to write:

IF sy-uname EQ 'BARDENS'.

Notice too that the ABAP compiler automatically converts the user ID (macro parameter &1) to uppercase. If only the ABAP debugger would let me walk through the substituted macro logic – this inability to debug (and hence increased difficulty to support) is the main reason I try to avoid using locally-defined macros.

A little bit of macro fun…

Warning! Table TRMAC is an SAP system table which is not meant to be maintained by customers. Removing or changing entries in this table could really mess with your SAP system. This could in turn land you in trouble.

If the warning doesn’t scare you and you feel like messing with a fellow ABAPer’s head, temporarily add the following macro definition to table TRMAC substituting their user ID in place of COLLEAGUE.


Next, create a new program with the following code and get them to run it under their user ID. It will break for your colleague, but not for you. 🙂

INTO TABLE gt_flights
FROM sflight.


i_structure_name = 'SFLIGHT'
t_outtab = gt_flights.

Side Note:

This presentation on SDN has a section on a new concept of activatable breakpoints being introduced with WAS 6.40.  These hardcoded breakpoints remain dormant until activated by configuration.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Peter Inotai
      Peter Inotai
      Hi Scott,

      Thanks for this weblog, it's very interesting.
      I've never heard about this feature with TRMAC before.

      After a quick search I found OSS note 3776 ('Restrictions in macros via DEFINE or in TRMAC' from 17.04.1993!!! ), which also contains an example.

      Best regards,
      Peter Inotai

      Author's profile photo Former Member
      Former Member
      A while back (on a 4.5B system) I had to change and debug a program which had lots of the break sy-uname statements for the previous developer. To make use of the break-points I would have had to change them all (and so would the next developer).
      So to be a little more selective about which berak points I activated, and so the next developer could use them. I created a parameter Id, and changed the code to:
      GET parameter-id xyz field l_abc.
      if l_abc ca 'M'.
      Now all I had to do was add the appropiate value(s) (in this case 'M') to my PID.

      Now if you combine the two ideas you can have activatable break-points in earlier releases.

      Nice tip.


      Author's profile photo Former Member
      Former Member
      That's a good and simple idea that hadn't crossed my mind.  I might actually define such a break-point macro on the next project.