Skip to Content
Author's profile photo Horst Keller

A word about CALL ‘SYSTEM’

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,
        line(255),
      END OF tabl.
     
command = ‘…’.
CALL ‘SYSTEM’ ID ‘COMMAND’ FIELD 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.

Second:

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 …

Third:

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 = ‘…’.
CALL ‘SYSTEM’ ID ‘COMMAND’ FIELD command
              ID ‘TAB’     FIELD tabl.

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

Assigned Tags

      16 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Uwe Fetzer
      Uwe Fetzer

      Hope this nice short blog will become No. 1 on Google and SCN search index.

      Author's profile photo Robson Soares
      Robson Soares

      Right now it is the no. 2 ๐Ÿ™‚

       

      Author's profile photo Tom Van Doorslaer
      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.

      Author's profile photo Frank Koehntopp
      Frank Koehntopp

      Gotta love small to-the-point security blogs.

      Great job!

      Author's profile photo Bjorn-Henrik Zink
      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?

      /Björn-Henrik

      Author's profile photo Horst Keller
      Horst Keller
      Blog 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.

      Best

      Horst

      Author's profile photo George Dedas
      George Dedas

      this is my question too....if the ย rdisp/call_system parameter is deactivated, will this infect the many standard SAP programs where it used?

      Author's profile photo Johannes Goerlich
      Johannes Goerlich

      In the ABAP Editor Documentation you can find

      "Calls of the system function SYSTEM with the internal statement CALL should never be made and can be deactivated using the profile parameter rdisp/call_system. If called, it then raises a non-handleable exception.

      Note: Before the statements CALL 'SYSTEM' is deactivated using the profile parameter rdisp/call_system, it must be ensured that it is no longer used in any programs. Any programs that still use CALL 'SYSTEM' must first be switched to use of the SXPG frameworks before the unwanted statement can be deactivated. The options in the SXPG frameworks generally cover all requirements when calling operating system statements."

      In a recent NW 7.52 i still can find 130 occurrences of "CALL โ€˜SYSTEMโ€™" in SAP standard coding, but I can not say if this coding is still in use.ย It is said, if you determine issues SAP will deliver a correction (this excludes for sure report RSBDCOS0).

       

      BR,

      Joe

      Author's profile photo abilash n
      abilash n

      Thanks for letting us know about this.....

      Author's profile photo Siva rama Krishna Pabbraju
      Siva rama Krishna Pabbraju

      Thanks a lot for the information. ๐Ÿ™‚

      Author's profile photo Former Member
      Former Member

      Thanks a lot it is very useful.

      Author's profile photo Former Member
      Former Member

      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.

      Author's profile photo Former Member
      Former Member

      Hi Horst Keller

      Really helful and informative blog.Awating for next blog ๐Ÿ™‚ .

      Thanks

      KH

      Author's profile photo Shakul Jugran
      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.

      BR

      Shakul.

      Author's profile photo Peter Kostur
      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.

      Cheers,

      Kosto

      Author's profile photo Yuvraj Chaudhari
      Yuvraj Chaudhari

      **CALL SYSTEM command is for internal use and should NOT be used in our application code.

      Instead of using CALL SYSTEM command, we can use the class "CL_CTS_LANGUAGE_FILE_IO". There are lot many methods of this class which will help us to complete our task.

      e.g: -ย  To list down directory list : Use method GET_DIRECTORY_LISTING ,

      -ย  To move/copy file from source to target : Use method COPY_FILES_LOCAL

       

      Regards,

      Yuvraj Chaudhari