job parameters in Execute Command of job sequence

[jreddy]

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.

[chulett]

That's a 'known issue'. Been that way since 5.something or other. Looks fine in the log, passes them untranslated to the command being executed.

FYI, you'll also find that the Email Notification stage has the same problem.

[jreddy]

Oh really.. i didnt notice that.

Thanks anyways, i have already spent enough time trying to figure out why it wasnt passing parameter values correctly.

Then what would an alternative be, if i have to call a shell script before certain job runs in the sequencer?

Thanks

[chulett]

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.

[jreddy]

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.

[chulett]

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:

Code: Select all

Call DSExecute("UNIX",CommandString,ScreenOutput,ReturnCode)

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.

[jreddy]

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

[chulett]

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:

Code: Select all

/tmp/tesh.sh Arg1 Arg2 Arg3 Arg4 Arg5

Then use that variable inside the call to DSExecute.

[kcbland]

Call DSExecute('UNIX', 'tesh.sh' Arg1 Arg2 Arg3 Arg4 Arg5, output, output)

This is syntactically WRONG. Anytime you pass two variables side by side, like this;

Code: Select all

VAR1 VAR2

the second variable acts as a FORMATTING string to the first variable. So, you are corrupting your command string with the contents of Arg1. Furthermore, you cannot see your fully composed command, so you don't see this happening.

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")

[jreddy]

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

[jreddy]

Hey Kenneth, Craig,

Got it done :D
Thanks so much for your help.

[jreddy]

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

[chulett]

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.