topic Using Unix date command in SM69 in Application Development and Automation Discussions

Using Unix date command in SM69

Former Member — Mon, 09 Feb 2015 15:03:45 GMT

Hi Experts,

I would like to use the Unix command DATE in SM69 and pipe the output in a file in a specific directory.

For example the unix command would look like this: date > /usr/sap/sst_data/APD/receive/ppk_kp8/test.txt

I tried several variants to enter the command parameters in SM69 but no one works fine.

Entering the whole command line in the first line in SM69 (operating system command) does not work too.

It seems that the system has a problem with the pipe command '>' to put the output in a file.

I receive the following error:

-------------------------------------------------------

date: extra operand `/usr/sap/sst_data/APD/receive/ppk_kp8/test.txt'

Try `date --help' for more information.

External program terminated with exit code 1

-------------------------------------------------------

All I would need is to create a file in a specific directory containing the actual timestamp.

Do you have any proposal what I did wrong?

Many thanks and best regards

Günter

Re: Using Unix date command in SM69

miko2 — Mon, 09 Feb 2015 15:36:18 GMT

Directories for SAP is in a different namespace form the oper.system. Try AL11 too see first if the file you want to right exists and has the same name as in the command.

Hope i help. Michael.

Re: Using Unix date command in SM69

jrg_wulf — Mon, 09 Feb 2015 16:12:02 GMT

Hi Günther,

this won't work since the redirect operator is not a parameter but a shell operator.

SM69 checks rather thoroughly, that to any given command, only listed parameters are provided.

If you need to redirect the output of your date command, you'll have to work around.

E.g. ask your os-team to create a small commandfile (script) to wrap your date command and provides the output redirection as parameter. Make it executable (chmod).

Then you can create an SM69 command with the pathname of that script and use a path as parameter on that.

That should do the trick.

Best regards - Jörg

BTW: the pipe operator is this | and it reroutes the ouput of one command as input for a second one. Not to be confused with the redirectors > for stdout and >> for stderr.

Re: Using Unix date command in SM69

jrg_wulf — Mon, 09 Feb 2015 18:13:45 GMT

Oh and another one.

Why do you bother with OS-command date?

You can retreive date and time as easily from SAP with get time, prepare it like whatever you need and than just output to file system, using open dataset and transfer.

BR - Jörg

Re: Using Unix date command in SM69

Former Member — Tue, 10 Feb 2015 06:36:44 GMT

Dear Jörg,

thanks a lot for your explanation!

The reason for my request is that we currently use the RFC_REMOTE_PIPE to execute some OS commands for creating, deleting and moving trigger files (for a prpcess chain) on OS level which should contain the timestamp.

Now we want to substitute the RFC_REMOTE_PIPE function and thats why I am searching for another solution to delet, create or move this little file and I tried to use OS commands in SM69 because I wanted to avoid abap programming.

So basically you helped already because now i know that it will not work to use '>' in SM69.

I will have a look at your proposal with using 'get time', open dataset,......but I am not good in ABAP.

If you know any other workaround your advice is really welcome.

Anyway.....many thanks for your input so far.

Günter

Re: Using Unix date command in SM69

jrg_wulf — Tue, 10 Feb 2015 09:08:36 GMT

Hi Günter,

regarding workaround - what about my earlier script suggestion?

It's easy enough to build, can be distributed or used on a share and gives the flexibility you need.

Surely, you have one or the other unix specialist capable of providing a two-line-script.

If all else fails, there's still the famed system call, where you can inout any actual command line.

With that even your redirection operator would work as intended.

Although i have to admit, it won't work on many systems due to restrictions and is definitely not a favourite of security concerned responsibles.

BR - Jörg