Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
Showing results for 
Search instead for 
Did you mean: 

Copy command called through FM SXPG_CALL_SYSTEM not performed properly

Former Member
0 Kudos

Hi Gurus,

I am calling the FM SXPG_CALL_SYSTEM with the command name as COPY maintained for windows NT server and I am passing the additional parameters with the file names ( source file <space> destination file). Source files can be picked using wild characters (for eg:filename_o_*.wrk) and all the files fetched from Source has to be placed into the one target file specified in the destination.

While performing this FM, we are getting error sometimes. suppose if there are two files present in the source, first part of first file and second part of second file is copied and not the whole file. So we are missing second part of first file and first part of second file. This happens randomly like once in a day. Can you please suggest how to rectify this error?

This is in High priority. Any immediate response is highly appreciated.

Please advice me the right forum for posting this if this is not the right forum.


Active Contributor
0 Kudos

You should get and analyze the result of the command (EXEC_PROTOCOL) so that to be able to investigate.

0 Kudos

The exec_protocal gives as File is copied but the complete file wil not be copied. Is there any way to get the problem to be fixed?

0 Kudos

Well, as it's not a SAP issue (SXPG_CALL_SYSTEM just calls "copy", that's all), you should better post it in a Windows forum, or search in the Microsoft KB (knowledge base) if there are corrections about that issue.

But are you really sure that, when the issue occurs, the protocol doesn't mention anything special? (as you say it occurs only once per day, do you store the protocol somewhere to be able to analyze it later?)

And are you sure the files are completely written when you start the copy? Did you take into account that the copy may not be synchronous, and maybe you delete files before they are totally copied...

0 Kudos

Make sure to use parameter "/b" of the copy command.

0 Kudos

/b is to indicate that the copy is to be done in binary mode. I don't understand how it would solve the issue?

Note that by looking at dos commands, we see the commands VERIFY ON and VERIFY OFF which should check that files are correctly copied...

0 Kudos

The symptoms described suggest that the problem may have something to do with the copying mode: ascii / binary. If you copy in binary mode all the bytes of the source file(s) are transferred to the destination exactly as they are stored in the source, but this does not have to be the case if you copy in ascii mode. In ascii mode some characters of the source stream may influence the copying process, for example character Ctrl-Z (hex 1A) indicates end of file so if you have some more bytes after this one in the source files they will not be copied to the destination.

See [here|] for more information (especially search the text for: "Using /a", "Using /b", "If you want to combine several binary files").


0 Kudos

Thx for the explanation, you're right! (very surprising to me)

Well, I tried on my XP SP 3 system:

When we use * or ?, then there's the issue you mention:

- For the test, I created 2 files named source1 and source2, one containing AAAA\[CTRLZ\]BBBB in my local encoding (cp1252), and the other CCCC\[CTRLZ\]DDDD.

- If I use COPY source* result, a new file "result" is created containing AAAACCCC\[CTRLZ\]. Note that \[CTRLZ\] is always added once at the end.

- If I do it with only one file but with a generic character (COPY sourc?1 result), there's the same issue.

- Same issue also if I copy a whole directory to a file (COPY directory result)

When I use COPY source1 result (only one source file, and no generic character * or ?), there's no issue.

When I use /b (COPY /b source* result), it works well. Note: be careful with /b position, COPY source* result /b, /b is ignored if it is at the end.

Doesn't explain why the beginning of a file was not copied, though.

0 Kudos

Hi Maciej & Sandra,

I am not sure whether the file is an ASCII file or Binary file. The Source file will be extended with *.wrk. Target file will be in *.txt. The data that comes into the file is IDOC data. when the RSNAST00 runs, all the idoc data will be sent into the file (as the source file *.wrk) and needs to be copied to *.txt (as destination). Can you please suggest what can be the better option of copy controls for this?

0 Kudos

1) whatever the file is text or any other "binary" type, you can perform a binary copy on both types of files, it means bytes are copied verbatim.

2) as you could see in my answer, it seems there is no error if you copy one file to another one. Moreover, it doesn't explain why one file is truncated at the beginning...

So, I'd recommend to try the copy with VERIFY ON ... VERIFY OFF, but I don't know if it works / how it works. You may also add a detection mechanism by comparing the copy (I let you find how to do it), that's slower, but at least you'll be able to take actions on the erroneous files.

0 Kudos

Definitely use copying in binary mode. This way you are sure that you copy the entire file properly - no matter what it contains.