Environment Variables vs JobParameters

[poorna_76]

We defined
DataSourceName,DatabaseUserName,DatabasePassword and ------ so many other things
as JobParameters and using them in our jobs.

Is it advisable to use DataSourceName,DatabaseUserName,DatabasePassword and ------ so many other things
as Environment variables and use them in the job,
for Production Jobs?

One of the BusinessAnalyst posed a question,
why not you use Environment variables for all the JobParameters,
instead of writting JobControl to read those parameters from a Parameter File.

Can you please clarify this.

Thanks in Advance.

[ray.wurlod]

Using environment variables for passwords means that there's somewhere on your system where the password is stored in clear.

Apart from that, there's no reason not to use environment variables if you want. However, here are several reasons that I'd tend still to use "proper" job parameters.

• Using a List, Date, Time, Integer or Float type can prevent invalid values (for example for DSN) being entered.
  
  Using one of those types (or Pathname) with no default can force a value to be entered when the job run request is made.
  
  Using a Pathname type automatically enables a file browser in the Job Run Options dialog.
  
  Encrypted types mean that the default value is reasonably secure (one can change the default value on the production system via Director).

I do use environment variables some times; it's always a case of choosing the right tool for the job.

[vmcburney]

I think in the very latest version they have fixed the handling of encrypted environment variables so you can set a project level environment variable as encrypted, add it as a job parameter, set it to $PROJDEF to always pick up the latest setting and use it in your job.

Previous versions did not work so well. This way there will be no place where the password is visible and administrators can use the Administrator tool to maintain passwords or update directly against the parameters file in the project directory.

I like project specific environment variables as they now support encrypted, but mainly for fully automated sites. If you have ad hoc jobs with job parameters that the users set at run time then as Ray points out straight job parameters are more flexible.

[roy]

Hi,
recently there was another post which also addressed the difference in maintaining and migrating those project variables between projects.

another thing effecting your decision.

[poorna_76]

Hi,
recently there was another post which also addressed the difference in maintaining and migrating those project variables between projects.

another thing effecting your decision.

Thanks for every one , for all the valuable suggestions.

[vmcburney]

Have managed to get encrypted environment variable passwords working in version 7.1 of DataStage. Created a database password environment variable using Administrator as a project level user defined environment variable of type Encrypted. This appears in the Administrator as ****** and in the DSParams file as junk text.

Added this environment variable to my job. It comes in as Encrypted with password of ******. At this point it will always run with the original password value. To make it fully dynamic I set the value to $PROJDEF.

Add the parameter into my database stage and run the job.

In the DataStage log the parameter comes up as ***** so it is fully protected in all places and cannot be seen in plain English.

[steve_thomps]

Hi, Steve here out in sunny Las Vegas. We have implemented a solution which parameterizes our db logon and passwords. We have chosen to use Environment Variables to do this. DataStage keeps track of these by preceeding the variable name with a '$'. It appears we have issues when a job calls a shared routine. The shared routine doesn't seem to allow Environment Variables, only job parameters. We are on v7.0.1.

Ideas?

[steve_thomps]

aaahh, ok, just figured it out. no problem. the environment variables don't appear to be valid in Shared Containers. Logically this makes sense, as one would normally not want static values for each and every individual Container call. (This goes against the logical purpose of shared containters.) But in our case we want any and all Shared Container calls to use the same db logon information.

I set up job parameters in the Container, and where the container is called, i passed it the Environment variables from the calling job.