Skip to Content
Author's profile photo Stefan Wolf

How called code can strangely influence your own program flow

The Problem

Because ABAP is a language with (too) many possibilities, called procedures can strangely affect the flow of the calling program. In some cases, even a trace does not clarify the behavior.

Sometimes this can be hard to figure out.

Known Cases

The cruel thing with the following commands is that they are performed anywhere, but affect later! So looking at the last performed command does not help.

set screen

If the code you are calling via a dynpro performs set screen 0, your dynpro will be left after your PAI has completely run.

If the called code performs set screen <nnnn> (<>0), this dynpro will be called after your PAI has completely run.

leave [to] screen

If the called code performs leave screen, the last set screen will be performed, and the calling program will not be continued.
If in this case the last set screen is 0, see set screen 0.

If in this case the last set screen <> 0, this screen will be performed.

If the called code performs leave to screen <nnnn> the same is true for dynpro nnnn.

suppress dialog

If you are calling code in your PBO that performs suppress dialog, the PAI of your dynpro will be processed as if the user would have hit enter (but he did not) although you even don´t see your dynpro (you still see the last dynpro).


As ABAPers we know that the message command can influence many many things, e. g. if the called program sends a message of type E your PAI-Module gets interrupted and no PBO is performed, but the program does not stop. But this command can do so much more strange things, this is why I call it the monster command 😯 .


Not such cruel, but also in this context interesting statements are:

  • call transaction
  • call screen
  • leave
  • leave program
  • leave list-processing
  • leave to current transaction
  • leave to list-processing
  • leave to transaction
  • submit
  • stop
  • exit from step-loop

A real life Example

We called BAPI_PROCORD_CHECK_MAT_AVAIL and after that call, the PAI was still processed and after PAI the program easily has ended.
See here: BAPI_PROCORD_CHECK_MAT_AVAIL affecting screen flow.

How does that help?

Well, next time I see such a strange behavior, I will set break points at the following commands:

  • set screen
  • leave
  • suppress dialog
  • message
  • call transaction
  • call screen
  • submit
  • stop
  • exit from step-loop

What did I miss?

Did I miss something? If you have more commands that could be interesting here, please tell me.

If you have any questions or other notes, please tell me.



Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      SUPPRESS DIALOG is the strangest of them all. I remember scratching my head for almost an hour before my eyes fell on this weird statement.

      This is where the use of in-line comments is so important, sometimes it's very difficult to understand the rationale behind such things. 🙁



      Author's profile photo Stefan Wolf
      Stefan Wolf
      Blog Post Author

      Believe me, set screen is also not bad 😯