Parameters to UNIX shell scripting from Routine

[sck]

Hi All,
I need to send parameters to UNIX shell scripting.

The scripts goes with the name ds_load.sh with four parameters as
arguments in it, like arg1, arg2, arg3 , agr4.

I see Call DSExecute command, but I am not sure as the
exact format as to how to send parameters are passed.

How can I send these values from a Job control routine?

For eg these values (all arg)are read from a hash file and then
these values are passed as parameters, thus this goes in a loop untill
all the rows in the HASH file are read.

Could anyone please help on this as to how this can be done.

Thanks

[chulett]

How can I send these values from a Job control routine?

Simplest thing is to create a 'command string' that looks pretty much just like you were running the script from the command line, but fully path the script. Do this by concatenating together the static bits and the parameters:

Code: Select all

UnixCmd = "/fullpath/ds_load.sh ":arg1:" ":arg2:" ":arg3:" ":arg4

Then use this string when calling DSExecute:

Code: Select all

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

Note that the variable names are made up, they can be anything you want but these give a good indication of what purpose they are serving. If ReturnCode is not zero, then Something Bad Happened. Anything output to the "screen" by the script will get captured in the ScreenOutput dynamic array.

FYI - Don't try doing the equivalent of this with the Command Execution Stage in a Sequence job, it still doesn't take Job Parameters. It looks like it does, but it doesn't.

[sck]

Thanks for the reply,

We are trying to concatenate the string
of the Shell Path and Arguments, does the shell take care
of the path and the arguments to it, how does this work,
and also is the Screen Output name necessary like
what does that imply.

[chulett]

I'm not sure what you are asking...

I suggested you fully path your script so that there are no issues with it not being able to find it to run it. One thing you'll quickly learn is the environment that scripts run under when executed via DataStage is very different from your command line - even when using the same userid. I wouldn't take anything for granted, including what you think your PATH environment variable is set to.

The script is executed just as if you pasted the end result of your concatenated string on the command line of your terminal session and pressed return. Make sure it is syntactically correct - arguments in the right order, white space between everything - and you should be fine... assuming you are starting with a working script.

And yes, the ScreenOutput part is required syntax for the DSExecute command. It's up to you do use it or ignore it as you please.

[sck]

Thanks Craig..
Here I am only confused when you try to concatenate the string with
the arguments...so here should the script should take care to see that
the agruments are passed to appropriate values in the script.
This question may be basic this is the first time I am working with
the Scripts. Yeah I have to start working on the Scripts.

Thanks

[chulett]

Ok. Sounds like you are in for some fun if this is virgin territory for you.

The scripts need to check, as much as possible, that the correct values have been passed in. Sometimes all that means is the correct number of values has been passed in and I'd suggest you do that at a minimum. Then, as much as possible, check the values. For example, if one of them is a directory you can check that it exists, is in fact a directory and that it has the correct permissions before moving on inside your script. Bottom line is - how much do you trust the people / jobs that will be using the scripts to get it right every time?

Make sure that you set the exit status of your scripts to something non-zero in the event of a problem so DataStage has a clue that something went wrong. Anything that the script echoes to the screen will get caught in the ScreenOutput variable and can therefor be logged.

Hope this helps...

[kduke]

Post why you think you need a shell script and several of us can help you write it or show you a better way. Mostly I use shell scripts to ftp files because I do not like the ftp stage. You can easily archive a file afterwards in a shell script. I think shell scripts are nice ways to initiate jobs too instead of waiting for a file. Just my way of using shell scripts. I am sure there are other important needs which can be met with a script.

[sck]

Hi All,

Thanks for your reply Craig and Duke.

This Shell Script initates a BCP load and then compares the file with the
total record count and then those files are used in the next jobs.

But here there is a problem, When I tried executing it

TEST #1
*******

Arg1 = /PATH/tblFHASH
Arg2 = /PATH/D_bcp.sh

Test completed.

DSLogInfo called from : GetStatusCheck
Message to be logged is...
> OREIGN,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,

[ray.wurlod]

That's a test from the Test Grid for a DataStage Routine.

If you want that (rather than a shell script) analyzed, you'll need to post the code. The routine has called DSLogInfo() with the first variable containing a lot of junk - perhaps the OREIGN comes from FOREIGN KEY.

Anyway, post the Routine source code and don your flame suit!

[kduke]

I think you got it backwards:

Code: Select all

UnixCmd = "/fullpath/ds_load.sh ":arg1:" ":arg2:" ":arg3:" ":arg4 

Code: Select all

Arg1 = /PATH/tblFHASH 
Arg2 = /PATH/D_bcp.sh 

Your shell script should be the first part of the UnixCmd like the above. There should not be an Arg2. My suggestion is to put all your shell scripts in a directory below the project called "scripts". You need to put the real path in where "PATH" is now.

Code: Select all

Arg1 = "/PATH/tblFHASH"
UnixCmd = "scripts/D_bcp.sh ":Arg1