How to pass parameters to a generic job script?

[vamsi_4a6]

I am developing generic UNIX script to call DataStage Job and stuck with how to form the logic for $paramlist because one job is having one parameter, another job has 3 job parameters and 3 parameter sets and it is not fixed. Currently I am passing one parameter for script (i.e job name)

${DS_HOME}/dsjob -domain ${DS_DOMAIN} -user ${DSRUN_USR} -password ${DS_RUN_USER_PW} -server ${DS_SERVER} -run $paramlist -jobstatus ${PROJECT_NAME} ${jobname}

Also - in one of the posts I saw a generic script to call a DataStage job. I am not able to find it now. Could anybody provide link for that?

[Thomas.B]

1 -> Maybe you can put all the parameters you have to process as last parameters of the UNIX script calling the DataStage job.
ex :

• 1st param : job name
  2nd param : user
  3rd param : psw
  All the other params are parameters to pass to the job

You can get the number of parameters passed to your script with the "$#" keyword

2 ->

2)In one of the post in dsexchange i saw generic script to call datastage job.Not able to find now.could anybody provide link for that?

Maybe this one ?
viewtopic.php?t=85578

[kduke]

Code: Select all

dsjob -lparams $DSProject $JobName

Will give you a list of parameters. If you send in a parameter to a job that does not exist in the job then it will fail. We put the parameter values in files. We would look for a parameter in jobname.prm. If it existed in this then we would run the job. If not then we would look for it in global.prm then run. You cannot run until you have values for all parameters without default values.

Code: Select all

ParamDefault=`$DSPath/dsjob -paraminfo $DSProject $JobName $ParamName 2>/dev/null | grep "Default Value" | cut -d":" -f2 | awk '{print $1}'`

Will tell you if a parameter has a default. You need to check for empty value to see if it has a default.

If you have parameter sets then all this gets a little more complex.

[UCDI]

you can also make all your top level jobs have 1 variable that is a file, or a database key, or whatever that provides the specific parameters in a list you can parse.

[ray.wurlod]

The dsjob command takes multiple occurrences of -param name=value

So your paramlist variable will contain something like

Code: Select all

-param name1=value1 -param name2=value2 -param name3=value3 ...

[FranklinE]

Expanding on Ray's point...

We have a complex parameter usage. The following are script code examples without further explanation because you really must have someone familiar with your system make the detailed decisions.

We source in project variables from a .ssi file as well. The first loop takes parameters passed from the calling system, in my case a Control-M command line. The next loops reference the variables from the .ssi file.

The final command line has other references which are explained in the DataStage manuals. Please note the lack of an authorization parameter. I can't show complete code for obvious reasons.

Code: Select all

###
# process input parameters.
###
while getopts d:e:g:p:j:w:r:P:Rh param
do
    case ${param} in
         d) envparam1=${OPTARG};;
         e) envparam2=${OPTARG};;
         g) prjparam1=${OPTARG};;
         p) prjparam2=${OPTARG};;
         j) jobname=${OPTARG};;
         w) WARN_LIMIT="-warn ${OPTARG}";;
         r) ROWS_LIMIT="-rows ${OPTARG}";;
         P) PARAMSTRING="${PARAMSTRING} -param ${OPTARG} ";;
         R) J_RESET=1;;
         h) Usage; exit 0;;
        \?) Usage; exit 8;;
    esac
done

###

for VAR in ${PUBLIC_PARAMETERS}
do
    PARAMSTRING="${PARAMSTRING} -param ${VAR}"
done

###

for VAR in ${OTHER_PARAMETERS}
do
    PARAMSTRING="${PARAMSTRING} -param ${VAR}"
done

###

${DSHOME}/bin/dsjob ${PORT_NUMBER} -run -jobstatus ${WARN_LIMIT} ${ROWS_LIMIT} ${PARAMSTRING} ${prjname} ${jobname}

[vamsi_4a6]

I am able to form the logic for parameters successfully when we have parameters.
Let us say i do not have any parameters for Job what i need to do to make it run for below command.I mean $paramlist is empty

${DS_HOME}/dsjob -domain ${DS_DOMAIN} -user ${DSRUN_USR} -password ${DS_RUN_USER_PW} -server ${DS_SERVER} -run $paramlist -jobstatus ${PROJECT_NAME} ${jobname}

[chulett]

Then you leave the variable unset.

[ray.wurlod]

Probably better to set it to "".

[chulett]

Sure but basically the same thing. Either set it an empty string first regardless and then set it to your parameter list when it needs it or simply leave it not set in the process's environment and then only set it when needed. In either case it be "empty" and will just basically not appear in the final, built command line.

[Teej]

Be careful when setting an environment variable, especially for PX Engine's APT_ variables. We use "isDefined()" internally to determine if it is actually defined, regardless of the value provided, for the vast majority of those environment variables.

So if you set "" as a value, you may run a risk of the system actually defining the environment variable. Use $UNSET within the job framework, or "unset" on the command line.

[chulett]

That's funny - all these years living over a UNIX basement and I don't ever really think of using "unset". I'm typically defining variables unique to process environments outside of our daily job runs and either not setting them unless needed or for Boolean values explicitly setting them to false before deciding if they ever need to be true or not.

Note to self...

[Teej]

That's quite understandable, but what is "on"? What is "off"?

1? 0? Yes? No? True? False? Hai? Iie? Our products are used worldwide, so it is far easier to explain, "unset it", then it is to set a value that only an English speaker may understand.

If you look closely at the already defined environment variables, you would notice that if you left the values as default, the GUI would internally unset these environment variables. You can find out this behavior by observing the message id IIS-DSTAGE-RUN-I-0126

-T.J.

P.S. Granted, I have been using unset before I joined Ascential for other things. Maybe I am just more of a shell scripting nerd than you are.