DSXchange

Hi

I would like to pass the value into dsjob command via unix script.

I am reading the values from a.txt file . a.txt file data looks like

year|design
2009|4 way
2010|2 way
2011|3 way

Inside unix script I have assgined the values as follow

//---------------------------------------------------------

reading for the file in loop

year=`echo $READ_LINE | cut -d "|" -f1`
design=`echo $READ_LINE | cut -d "|" -f2`

echo $year , $design

dsjob -run -mode NORMAL -warn 0 -param YEAR=$year -param DESGIN=$desgin -wait -jobstatus <projectname> file_Extract_test

//---------------------------------------------------------------------------

I am getting Invalid arguments: dsjob -run error.

But when I run the dsjob from command line and it works fine without issue but passing parameter is giving error even via command line too.

working one
---------------
dsjob -run -mode NORMAL -warn 0 -param YEAR=2009 -param DESGIN="$desgin4 way" -wait -jobstatus <projectname> file_Extract_test

Not working
------------------
echo $year , $design

dsjob -run -mode NORMAL -warn 0 -param YEAR=$year -param DESGIN=$desgin -wait -jobstatus <projectname> file_Extract_test


Is there is any format to send value like "4 way"?

Thanks
Man

-param DESGIN=$desgin

It is "DESIGN" I assume... are you doing it correctly and the typo is just in your post?

ps. Always best to explain what "not working" means and to include any errors you get rather than making us guess what they might be.

1) sh -v scriptname.ksh to see what is substituted for each parameter
to find the where is the problem for each iteration

include within double quotes:

That would turn the environment variable into a simple string.

chulett wrote:That would turn the environment variable into a simple string.

I doubt this. since returns 2 and not $a.
please correct me if i am wrong

Well... we're not talking echo here but I could be wrong. Have no way to test it, however.

The same situation here .. No datastage system to test

I just happened to have a linux prompt handy...
Pandeesh, here is a small dose of theory about why you are correct:

What happens on unix (linux, aix, etc) is the shell tokenizes your input and replaces $whatever with the env-value if available.

Quoted expressions are treated as a single token.
Suppose we have a simple shell script "foo.sh" like this:
-----
$ cat foo.sh
echo "Hi from foo, param1=<$1> param2=<$2> param3=<$3>"
$ chmod +x foo.sh
$ ./foo.sh
Hi from foo, param1=<> param2=<> param3=<>
-----

The following sends 3 parameters to foo (each param is 1 char long).
-----
$ ./foo.sh x y z
Hi from foo, param1=<x> param2=<y> param3=<z>
-----

This sends 1 parameter to foo (the param is 5 chars long, and it has embedded spaces).
-----
$ ./foo.sh "x y z"
Hi from foo, param1=<x y z> param2=<> param3=<>
-----

Now for an environment variable:
-----
$ bar=alpha
$ ./foo.sh $bar y z
Hi from foo, param1=<alpha> param2=<y> param3=<z>
-----

Double quotes still expand env vars...
-----
$ ./foo.sh "$bar y z"
Hi from foo, param1=<alpha y z> param2=<> param3=<>
-----

While single quotes do not...
-----
$ ./foo.sh '$bar y z'
Hi from foo, param1=<$bar y z> param2=<> param3=<>
-----

Lastly, consider string concatenation (which is handy if you want to do things like build file names):
-----
$ ./foo.sh $baryz
Hi from foo, param1="" param2="" param3=""
-----
Here param1 was empty because there is no env-var named $baryz.

To get at the actual value of just $bar, you can use curly braces:
-----
$ ./foo.sh ${bar}yz
Hi from foo, param1="alphayz" param2="" param3=""
-----

Google "unix shell quoting" for more: it can get complex, but understanding the above is enough to let you predict how things will behave.

A key point keep in mind is that all the env-var evaluation happens before the target command ever starts to run. All the command (for example, dsjob) will see is a list of 0 to many strings, each string represents an argument and the length of a string can be zero.
For this thread you can use double quotes to control the boundaries of those strings; outside of quotes they are white-space delimited.

This also applies to file wild cards.
Consider this:
$ ./foo.sh *.dat
Before running your program, the shell looks for files matching *.dat. If the shell finds any, *.dat is replaced with that list of file name(s). If the shell doesn't find any, *.dat is passed as-is (e.g. 5 chars) as the first argument string the command will see.

(be advised that windows follows different rules; if you're writing shell scripts or batch files or powershell it is worth studying up on how env-var and wildcard processing works)

pandeesh wrote:

chulett wrote:That would turn the environment variable into a simple string.

I doubt this. since

Code: Select all

 a=2
echo "$a" 

returns 2 and not $a.
please correct me if i am wrong