$CommandOutput
Moderators: chulett, rschirm, roy
$CommandOutput
I have a sequence job using execute_command. In execute command, I put the following command:
cat /test/chk_total_record.txt | sed s/\"//g
and the return result is 0
in Trigger, I specify Expression type - Custom - (conditional) and Expression - left(Execute_Command_1.$CommandOutput,1) =0
which I expect it to go to next task E-mail Notification_Activity. It didn't, instead it went to other task
left(Execute_Command_1.$CommandOutput,1) <>0
Where did I do wrong? Thanks!
cat /test/chk_total_record.txt | sed s/\"//g
and the return result is 0
in Trigger, I specify Expression type - Custom - (conditional) and Expression - left(Execute_Command_1.$CommandOutput,1) =0
which I expect it to go to next task E-mail Notification_Activity. It didn't, instead it went to other task
left(Execute_Command_1.$CommandOutput,1) <>0
Where did I do wrong? Thanks!
well, in this sequence job I have one job parameter data_loc which default set to test, and in the execute command: I coded cat /#data_loc#/chk_total_record.txt | sed s/\"//g
However when job ran, got the following error message, /test/chk_total_record.txt A file or directory is not found. That indicates, for some reason it could not parse job parameter data_loc as test. Stranger enough, in the job log it did replace #data_loc# as test though. So I decide to hard-coded test instead of using parameter #data_loc# and it works perfectly. Any idea, why?
Thanks,
However when job ran, got the following error message, /test/chk_total_record.txt A file or directory is not found. That indicates, for some reason it could not parse job parameter data_loc as test. Stranger enough, in the job log it did replace #data_loc# as test though. So I decide to hard-coded test instead of using parameter #data_loc# and it works perfectly. Any idea, why?
Thanks,
Unfortunately, that's the way the Execute Command stage works - and it's confusing as all get out.
Your job parameters are translated in everything that it logs, so it looks great there - however, the actual command sent to the O/S doesn't get the parameters translated so it fails. Stupid.
You either need to hard-code things or switch to the Routine Activity stage and call DSExecute yourself - which will handle the parameters.
Your job parameters are translated in everything that it logs, so it looks great there - however, the actual command sent to the O/S doesn't get the parameters translated so it fails. Stupid.
You either need to hard-code things or switch to the Routine Activity stage and call DSExecute yourself - which will handle the parameters.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
Gday,
I was wondering if anybody could expand on executing the Unix command from a Routine Activity Stage using Dsexecute. I'm assuming you create a Routine and pass in any Job Parameters as Arguments? Is that correct? My Parameter is basically the path of the Unix script I wanted to execute
Then in the code of the routine the syntax would be
Ans=DSExecute(UV,Arg1:"/ScriptName",Out,0)
where Arg1 is the Path Job Parameter
I'm probably way off with the syntax so any help would be appreciated
Cheers,
Lawrence
I was wondering if anybody could expand on executing the Unix command from a Routine Activity Stage using Dsexecute. I'm assuming you create a Routine and pass in any Job Parameters as Arguments? Is that correct? My Parameter is basically the path of the Unix script I wanted to execute
Then in the code of the routine the syntax would be
Ans=DSExecute(UV,Arg1:"/ScriptName",Out,0)
where Arg1 is the Path Job Parameter
I'm probably way off with the syntax so any help would be appreciated
Cheers,
Lawrence
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
The first argument of DSExecute is the shell name, you've used UV which is a variable name. That's fine so long as you've assigned the value "UV" or "DOS" or "UNIX" to that variable, but a more meaningful variable name is warranted.
The second argument is whatever must be executed. If Arg1 (another less-than-meaningfully named variable) contains the parent directory of Scriptname and Scriptname is what you want to execute and the user running the job has execute permission to it, then you're on the right track with this one.
The third argument must be a variable name, as it captures the output from the executed command, with any line terminators converted to field marks (@FM).
The fourth argument must also be a variable name, as it captures the exit status of the executed command. You slipped up on that one.
I'm guessing you want to call this from a job sequence. What's wrong with an Execute Command activity, so that you don't carry an unnecessary level of redirection?
The second argument is whatever must be executed. If Arg1 (another less-than-meaningfully named variable) contains the parent directory of Scriptname and Scriptname is what you want to execute and the user running the job has execute permission to it, then you're on the right track with this one.
The third argument must be a variable name, as it captures the output from the executed command, with any line terminators converted to field marks (@FM).
The fourth argument must also be a variable name, as it captures the exit status of the executed command. You slipped up on that one.
Code: Select all
Call DSExcecute("UNIX", Arg1 : "/ScriptName", Output, ExitStatus)
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Thanks for your help Ray,
I've currently got the script executed in a Execute Command Activity but because the path is a Job Parameter, it doesn't seem to convert the Job Parameter to the value I pass it when executing. Therefore I've got the path hardcoded, and have to remember to change the path explicity when I'm migrating to a diff environment, which I wanted to avoid.
Cheers,
Lawrence
I've currently got the script executed in a Execute Command Activity but because the path is a Job Parameter, it doesn't seem to convert the Job Parameter to the value I pass it when executing. Therefore I've got the path hardcoded, and have to remember to change the path explicity when I'm migrating to a diff environment, which I wanted to avoid.
Cheers,
Lawrence
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Are you putting the job parameter reference (#paramname#) in the Command field or the Parameters field?
I seem to recall that it's only resolved if it's in the Parameters field.
I seem to recall that it's only resolved if it's in the Parameters field.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
That's correct. Job Parameters do resolve if they are in the parameters field. However as my parameter is a path of the actual command
#path#/command
rather than a path of a parameter that is passed to the command
command #path#/parameter
I haven't been able to structure the command so that the path is in the parameter field. If it can be done it would make it easier for me, but I've changed the jobs to use a routine, and it works fine.
Cheers,
Lawrence
#path#/command
rather than a path of a parameter that is passed to the command
command #path#/parameter
I haven't been able to structure the command so that the path is in the parameter field. If it can be done it would make it easier for me, but I've changed the jobs to use a routine, and it works fine.
Cheers,
Lawrence
I believe that some of this behaviour is version dependant. For example, in 7.0.1 job parameters do not resolve in either field. Glad that they seem to have 'fixed' it in later versions, but they should have fixed it proper, allowing them in both fields.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
-
- Charter Member
- Posts: 166
- Joined: Wed Mar 16, 2005 6:52 am
- Location: Mumbai, India
The problem with the execute command stage is the it tries to execute the following:
<Command text> <Parsed Parameter text>
The space between the 2 is the killer.
And the command textbox cannot be empty or space. (DataStage checks for that )
How about writing a shell script you call with the entire command as a parameter. the shell script executes the command and returns the code and output.
<Command text> <Parsed Parameter text>
The space between the 2 is the killer.
And the command textbox cannot be empty or space. (DataStage checks for that )
How about writing a shell script you call with the entire command as a parameter. the shell script executes the command and returns the code and output.
Amey Vaidya<i>
I am rarely happier than when spending an entire day programming my computer to perform automatically a task that it would otherwise take me a good ten seconds to do by hand.</i>
<i>- Douglas Adams</i>
I am rarely happier than when spending an entire day programming my computer to perform automatically a task that it would otherwise take me a good ten seconds to do by hand.</i>
<i>- Douglas Adams</i>
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact: