Usage of $ENV variable

[dnat]

Hi,

I have a job which needs to be re-used with multiple parameters.

The job has an oracle stage which extracts data and stores it in a file.

I have the same table in different schema. So each has different value for schema/userid and password(Encrypted). All these values need to be stored in Datastage Administrator.

We have the following parameters for the job

Source_schema
Source_user_id
Source_password

These parameters need to have different values for different runs. But these are parameterized in administrator as the password value need to be encrypted.

I thought of setting the values for these parameters during each run in unix with export command and use $ENV. But i think this value will be overriden during the run which will take the value from Administrator, isnt it..

Is there a way to store the values like this in administrator and pass those values to the job during job run..

In Administrator

Source_schema1=xxxx
Source_schema2=yyyy
Source_userid1=nnnn
Source_userid2=hjbj
Source_password1=*****(Encrypted)
Source_password2=******(Encrypted).

and when the job runs

Source_schema should be passed with value of Source_schema1
Source_userid should be passed with the value of Source_userid1
Source_password should be passed with the value of Source_password1

[chulett]

Me, I wouldn't advise the use of environment variables for parameters that need to change run to run. Sure, you can setup values like that but you'd need a Sequence job to pick up 'schema1' and then pass it to 'schema', etc. And a different one for the 'twos'.

[dnat]

Thanks Craig, but is there a reason that you would not prefer to have environment variables to be passed..
In one of the projects i did use it and found it to be very easy..so just curious to know the drawbacks.

[chulett]

Please realize that I specifically said I didn't recommend it for parameters with values that need to change from run to run. They are suited for parameters that change value from environment to environment (hence the name) - typically ones that change from dev to test to prod like database credentials. As you said, that is the 'very easy' part.

Not saying you can't do it, obviously you can. Seems like you'd have to set up every permutation and then selectively feed the proper set in as already discussed or be willing to update each job's environment on the fly before starting them.

All IMHO, of course.