DSExecute problem
Moderators: chulett, rschirm, roy
DSExecute problem
Hi all,
I've tried to use sequencer and server job to execute unix command in different ways but i found there's a problem..
when i try to execute "mv #inputfile# #outputfile#"
it seems that datastage really run this command(accept "#inputfile#" as parameter) instead of passing parameters to the command (in director it shows the following,
Usage: mv [-i | -f] [--] src target
or: mv [-i | -f] [--] src1 ... srcN directory)
. And so it only works when i hardcode the parameters. Anyone can help?
Thanks,
Cal
I've tried to use sequencer and server job to execute unix command in different ways but i found there's a problem..
when i try to execute "mv #inputfile# #outputfile#"
it seems that datastage really run this command(accept "#inputfile#" as parameter) instead of passing parameters to the command (in director it shows the following,
Usage: mv [-i | -f] [--] src target
or: mv [-i | -f] [--] src1 ... srcN directory)
. And so it only works when i hardcode the parameters. Anyone can help?
Thanks,
Cal
Cal
it's essential to compose the command string the right way. I never used sequencer, but did something similar as ExecSH -> before-job sobroutine, where you wouldn't have the "" around the command. If this is no solution, maybe you have to concatenate(:) the elements of the command like:
"mv ":#inputfile#:" ":#outputfile#" or
"mv ":inputfile:" ":outputfile"
Thus the actual values for #inputfile# and #outputfile# are passed.
As everything after '#' on a shell command line is considered to be comment, the shell got just "mv " and therefore issued the usage message.
Stephan
it's essential to compose the command string the right way. I never used sequencer, but did something similar as ExecSH -> before-job sobroutine, where you wouldn't have the "" around the command. If this is no solution, maybe you have to concatenate(:) the elements of the command like:
"mv ":#inputfile#:" ":#outputfile#" or
"mv ":inputfile:" ":outputfile"
Thus the actual values for #inputfile# and #outputfile# are passed.
As everything after '#' on a shell command line is considered to be comment, the shell got just "mv " and therefore issued the usage message.
Stephan
-
- Participant
- Posts: 3593
- Joined: Thu Jan 23, 2003 5:25 pm
- Location: Australia, Melbourne
- Contact:
That's correct except in a sequence stage you don't need to use the # around parameter names.
In an execute stage just put this into the command field:
mv
And this into the command line parameter field:
inputfile : " " : outputfile
Vincent McBurney
Data Integration Services
www.intramatix.com
In an execute stage just put this into the command field:
mv
And this into the command line parameter field:
inputfile : " " : outputfile
Vincent McBurney
Data Integration Services
www.intramatix.com
Cal,
This issue has already been sent to Ascential (07/10/2002 & 03/09/2003) and was originally reported in version 5.2.1. The article or case number(s) are G18903 and G9065.
This is considered an enhancement and there is no timeline for when it will be enhanced.
Many times it is a good (first) idea to check the Ascential e-Support website then check the forum. I have seen many of the items posted here that have either been submitted to Ascential or fixed in a certain release.
Article G9065 (07/10/2002) does give a workaround to this as editing the job control code. This cannot be done from the job control window, rather there are other ways to do this, although should not be taken lightly and I won't give out this information to the general population. Those of you who know how to do it - will and those that do not probably should not be doing it.
Michael Hester
This issue has already been sent to Ascential (07/10/2002 & 03/09/2003) and was originally reported in version 5.2.1. The article or case number(s) are G18903 and G9065.
This is considered an enhancement and there is no timeline for when it will be enhanced.
Many times it is a good (first) idea to check the Ascential e-Support website then check the forum. I have seen many of the items posted here that have either been submitted to Ascential or fixed in a certain release.
Article G9065 (07/10/2002) does give a workaround to this as editing the job control code. This cannot be done from the job control window, rather there are other ways to do this, although should not be taken lightly and I won't give out this information to the general population. Those of you who know how to do it - will and those that do not probably should not be doing it.
Michael Hester
Cal
I think the workaround is to run a job that executes the shell script. That would have to work. You can pass the parameters to the job.
Michael is the bug list available to users?
Kim.
Kim Duke
DwNav - ETL Navigator
www.Duke-Consulting.com
I think the workaround is to run a job that executes the shell script. That would have to work. You can pass the parameters to the job.
Michael is the bug list available to users?
Kim.
Kim Duke
DwNav - ETL Navigator
www.Duke-Consulting.com
Kim,
Not that I know of. There is an exhaustive list of bugs, enhancements etc.. although they are not made public (for obvious reasons).
A good bet is that if the customer has maintenance and you have a login to the e-Support site then you can search and possibly find an answer. This is really quite a good site and getting better all the time. I have experienced great success with researching many of my issues and resolving them prior to posting or perusing forum sites.
Michael Hester
Not that I know of. There is an exhaustive list of bugs, enhancements etc.. although they are not made public (for obvious reasons).
A good bet is that if the customer has maintenance and you have a login to the e-Support site then you can search and possibly find an answer. This is really quite a good site and getting better all the time. I have experienced great success with researching many of my issues and resolving them prior to posting or perusing forum sites.
Michael Hester