job parameters in Execute Command of job sequence
Moderators: chulett, rschirm, roy
job parameters in Execute Command of job sequence
Guys,
Has anyone experimented using Job parameters as input parameters to a shell script that is called using the EXECUTE COMMAND in a job sequencer? If i put hard coded values in the parameters box, the shell script is executed fine. But when i use job parameters (defined in the sequencer as well), the Director log shows that it substituted them fine in the 'info' messages, but actually doesnt pass them onto the shell script at run time.
has anyone tried this before.
Thanks in advance.
Has anyone experimented using Job parameters as input parameters to a shell script that is called using the EXECUTE COMMAND in a job sequencer? If i put hard coded values in the parameters box, the shell script is executed fine. But when i use job parameters (defined in the sequencer as well), the Director log shows that it substituted them fine in the 'info' messages, but actually doesnt pass them onto the shell script at run time.
has anyone tried this before.
Thanks in advance.
A couple of options:
Before/After job subroutines handle parameters just fine. You can call your script from the first or last job in the Sequence. Not very obvious.
Or write a routine that calls your script, it can take parameters using the Routine Activity stage.
Before/After job subroutines handle parameters just fine. You can call your script from the first or last job in the Sequence. Not very obvious.
Or write a routine that calls your script, it can take parameters using the Routine Activity stage.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
i cannot use the first option, coz my requirement is that this shell script in turn calls a pl/sql procedure to go set some value in a table. And immediately after that there are two jobs that go off simultaneously (and they both use that value in that table). So, i cannot write a before job subroutine for either job.
Second option sounds good, but can you give me a brief note on how to write the routine that calls a shell script. A server routine takes only one input argument right, but i have about 7 input parameters that i want the shell script to use, out of which 4 are job parameters and rest others are hard coded values.
thanks for your time. appreciate it.
Second option sounds good, but can you give me a brief note on how to write the routine that calls a shell script. A server routine takes only one input argument right, but i have about 7 input parameters that i want the shell script to use, out of which 4 are job parameters and rest others are hard coded values.
thanks for your time. appreciate it.
Sorry, had things to accomplish today.
Now at home I don't have access to DataStage, so 'from memory' will have to suffice...
Basically, write a routine with however many arguments you need. They support only one return value, but allow multiple input arguments. Check the online help for 'DSExecute' which is what you'll need to use to call your script after building the full command string from your arguments. From what I recall, the syntax is:
The ReturnCode can be used to check the exit status of your script and the ScreenOutput dynamic array will capture anything your script echoes out.
Keep in mind this is all written from a Server job standpoint and your post indicates PX, so this may need to be handled differently. If so, hopefully one of the PX heavies will chime it with any caveats.
As an aside, the restriction of only one return value from a routine can be easily subverted by passing back a delimited string (or a dynamic array) to be parsed back apart later.![Cool 8)](./images/smilies/icon_cool.gif)
![Smile :)](./images/smilies/icon_smile.gif)
Basically, write a routine with however many arguments you need. They support only one return value, but allow multiple input arguments. Check the online help for 'DSExecute' which is what you'll need to use to call your script after building the full command string from your arguments. From what I recall, the syntax is:
Code: Select all
Call DSExecute("UNIX",CommandString,ScreenOutput,ReturnCode)
Keep in mind this is all written from a Server job standpoint and your post indicates PX, so this may need to be handled differently. If so, hopefully one of the PX heavies will chime it with any caveats.
As an aside, the restriction of only one return value from a routine can be easily subverted by passing back a delimited string (or a dynamic array) to be parsed back apart later.
![Cool 8)](./images/smilies/icon_cool.gif)
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
thanks buddy,
But again, when i was trying to implement this, had another doubt. Where do i specify the path of the shell script.
I have used
Call DSExecute('UNIX', 'tesh.sh' Arg1 Arg2 Arg3 Arg4 Arg5, output, output)
When i run it, it is supposed to call a pl/sql inturn and update a table, but it doesnt, which is natural, coz it didnt find test.sh in its current path. So, where can i put the path to the shell script. Assuming my shell script executes from /tmp/ directory, where should i put that in.. if i put it within quotes '/tmp/tesh.sh' doesnt work.
Wondering how to get that to work. Help me out here buddy
But again, when i was trying to implement this, had another doubt. Where do i specify the path of the shell script.
I have used
Call DSExecute('UNIX', 'tesh.sh' Arg1 Arg2 Arg3 Arg4 Arg5, output, output)
When i run it, it is supposed to call a pl/sql inturn and update a table, but it doesnt, which is natural, coz it didnt find test.sh in its current path. So, where can i put the path to the shell script. Assuming my shell script executes from /tmp/ directory, where should i put that in.. if i put it within quotes '/tmp/tesh.sh' doesnt work.
Wondering how to get that to work. Help me out here buddy
I've found it best to build a string which holds the entire command and then pass that to DSExecute. You hit on the classic problem with environments and DataStage jobs - what exactly does it look like when it runs? Best to not assume anything about your environment, so your solution is to fully path the call to your script, and by making it look exactly like it would if you typed it on the command line.
Build a variable, the contents of which looks like:
Then use that variable inside the call to DSExecute.
Build a variable, the contents of which looks like:
Code: Select all
/tmp/tesh.sh Arg1 Arg2 Arg3 Arg4 Arg5
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
This is syntactically WRONG. Anytime you pass two variables side by side, like this;jreddy wrote: Call DSExecute('UNIX', 'tesh.sh' Arg1 Arg2 Arg3 Arg4 Arg5, output, output)
Code: Select all
VAR1 VAR2
Try:
Code: Select all
UnixCmd = "test.sh ":Arg1:" ":Arg2:" ":Arg3:" ":Arg4:" ":Arg5
Call DSLogInfo("Executing UNIX command ":UnixCmd, "Msg")
Call DSExecute("UNIX", UnixCmd, ScreenOutput, ReturnCode)
Call DSLogInfo("UNIX command return code [":ReturnCode:"] ScreenOutput ":@AM:ScreenOutput, "Msg")
Kenneth Bland
Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
Thank you both for the suggestions.
But i am stuck again with same issue i faced with EXECUTE COMMAND, the parameters that i passed through to the shell script had to be passed as arguments to the pl/sql code. But apparently even though it shows in the director log that it has substituted correct values, the pl/sql procedure is not getting the actual values and hence gives error.
Are we sure that it is not a similar issue with ROUTINE ACTIVITY as it is with EXECUTE COMMAND?
Appreciate your help
But i am stuck again with same issue i faced with EXECUTE COMMAND, the parameters that i passed through to the shell script had to be passed as arguments to the pl/sql code. But apparently even though it shows in the director log that it has substituted correct values, the pl/sql procedure is not getting the actual values and hence gives error.
Are we sure that it is not a similar issue with ROUTINE ACTIVITY as it is with EXECUTE COMMAND?
Appreciate your help
Just wanted to share this other alternative too.. was experimenting a little more even after i got it done following your suggestion.
I realised we didnt have to write a routine for calling this shell script. In the routine activity, i can use the ExecSH and for the input argument, i gave the name of shell script along with job parameters (just as i would, in a before and after job subroutine). It worked fine
Used this in the input Argument prompt
'/tmp/test.sh':' ':param1:' ':param2:' ':param3:' ':param4:' ':param5
I realised we didnt have to write a routine for calling this shell script. In the routine activity, i can use the ExecSH and for the input argument, i gave the name of shell script along with job parameters (just as i would, in a before and after job subroutine). It worked fine
![Razz :P](./images/smilies/icon_razz.gif)
Used this in the input Argument prompt
'/tmp/test.sh':' ':param1:' ':param2:' ':param3:' ':param4:' ':param5
Excellent. :D
Kinda forgot about 'ExecSH' from the Routine stage as I tend to think of that as something available only as a before/after job subroutine, but you can certainly use it like that. The only 'advantage' to wrappering it with a Routine is illustrated in Ken's code - you can get a little more verbose, log (hopefully) more meaningful information, handle errors more gracefully, things like that.
Glad you got it sorted out.
Kinda forgot about 'ExecSH' from the Routine stage as I tend to think of that as something available only as a before/after job subroutine, but you can certainly use it like that. The only 'advantage' to wrappering it with a Routine is illustrated in Ken's code - you can get a little more verbose, log (hopefully) more meaningful information, handle errors more gracefully, things like that.
Glad you got it sorted out.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers