Skip to Content

When you google “ABAP CALL SYSTEM” you find a lot of entries that show code like the following:

DATA: command(255),
      BEGIN OF tabl OCCURS 0,
      END OF tabl.
command = ‘…’.
              ID ‘TAB’     FIELD tabl*sys*.

Fist of all:

You shouldn’t use CALL ‘SYSTEM’ at all. CALL ‘SYSTEM’ is vulnerable against system command injection and there is a profile parameter rdisp/call_system that can switch that call simply off. A runtime error occurs if you use CALL ‘SYSTEM’ and it is switched off. Do you want to risk that in your programs? If you have to use system calls, use function modules like SXPG_CALL_SYSTEM or SXPG_COMMAND_EXECUTE instead.


What is CALL ‘SYSTEM’?

CALL ‘SYSTEM’ is simply a usage of the ABAP statement CALL cfunc. This statement should only be used internally in system programs to call system functions from the c-kernel. SYSTEM is simply one of those system functions. It passes system commands to the operating system and returns the results. You should not call this function at all, see above …


What the heck is  tabl*sys*?

I suspect that most people writing in discussions about CALL ‘SYSTEM’ have copied their code from somewhere and that the original source is very, very old. If you believe that  tabl*sys* is somehow connected to CALL ‘SYSTEM’ – and I have the impression that some people do – you are perfectly wrong.

tabl*sys* is the outdated and undocumented way of writing tabl[] in order to address the table body of an internal table with header line. That’s all.

And of course, you don’t even need an internal table with header line for CALL ‘SYSTEM’ (some people seem to believe that too …)!

You could also write:

DATA: command TYPE char255,
      tabl    TYPE TABLE OF char255.

command = ‘…’.
              ID ‘TAB’     FIELD tabl.

No black magic, and as I said you shouldn’t use it anyway …

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Tom Van Doorslaer

    After reading the title “A word about using Call System” I was expecting a message body containing one single word: “Don’t”

    It turned out to be more than only one word, but the message is the same 🙂

    Now lets hope people stop using call-system commands.

  2. Bjorn-Henrik Zink

    Thanks for sharing Horst. You mention the rdisp/call_system parameter, would you generally recommend the parameter to be switched off or does that imply standard functionality to stop working as intended?


    1. Horst Keller Post author

      Hi Björn-Henrik,

      I asked som people who should know, but the fact is, nobody knows 😥 .

      I guess, the parameter rdisp/call_system was introduced to be able to switch of CALL ‘SYSTEM’ one day when all occurrences are cleaned up, but I fear that day will never come.



  3. Marcus von Cube

    Thanks for sharing your thoughts!

    But there are cases where I have yet to find a better solution. My problem is moving/renaming of a file. This works fine with a system command (SM69) which executes “rm” on Unix in most cases, but fails miserably if any of the file names passed as parameters contains a blank. On a shell prompt I can escape the space with a backslash or enclose the argument in single or double quotes. For unknown reasons, a call to a SM69 defined command does not follow the shell rules and the command fails. A possible workaround, use “sh -c mv” instead to force executing the mv command trough a shell to ensure proper argument parsing, fails because the arguments are stripped (quoted or not: try “sh -c echo Hello World” in SM69!). I consider the behavior stated above a bug.

    call ‘SYSTEM’ works fine with quoted arguments because the call is internally routed through a shell.

  4. Shakul Jugran

    Thanks for the tip Horst.

    I just ran into code inspector checks in my project regarding the CALL ‘SYSTEM’ construct and some curiosity led me to your blog 🙂

    Short and informative.



  5. Peter Kostur

    Long time ago I was thinking how big security hole it is and what everything I can do with it. Today I use it for low level stuff development from ABAP. But still it is security problem which can have very easy solution how to allow this but have it also under control. The problem is that each command call has same user rights as user used for running SAP instance what is pretty high OS level authorization. With determining different OS user for such commands called from ABAP the authorization can be limited. For me as developer is best to choose which OS user to use to which command call (of course user name and password will be stored in secure area). The old standard SAP code can use default user but for custom development will be needed to define different one. Maybe once such solution will come.




Leave a Reply