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.
Environment Variables vs JobParameters
Moderators: chulett, rschirm, roy
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
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.
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).
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
-
- Participant
- Posts: 3593
- Joined: Thu Jan 23, 2003 5:25 pm
- Location: Australia, Melbourne
- Contact:
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.
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.
Certus Solutions
Blog: Tooling Around in the InfoSphere
Twitter: @vmcburney
LinkedIn:Vincent McBurney LinkedIn
Blog: Tooling Around in the InfoSphere
Twitter: @vmcburney
LinkedIn:Vincent McBurney LinkedIn
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.
recently there was another post which also addressed the difference in maintaining and migrating those project variables between projects.
another thing effecting your decision.
Roy R.
Time is money but when you don't have money time is all you can afford.
Search before posting:)
Join the DataStagers team effort at:
http://www.worldcommunitygrid.org
Time is money but when you don't have money time is all you can afford.
Search before posting:)
Join the DataStagers team effort at:
http://www.worldcommunitygrid.org
-
- Participant
- Posts: 3593
- Joined: Thu Jan 23, 2003 5:25 pm
- Location: Australia, Melbourne
- Contact:
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.
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.
Certus Solutions
Blog: Tooling Around in the InfoSphere
Twitter: @vmcburney
LinkedIn:Vincent McBurney LinkedIn
Blog: Tooling Around in the InfoSphere
Twitter: @vmcburney
LinkedIn:Vincent McBurney LinkedIn
-
- Participant
- Posts: 2
- Joined: Fri Sep 10, 2004 11:12 am
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?
Ideas?
Last edited by steve_thomps on Thu Jun 09, 2005 4:07 pm, edited 1 time in total.
-
- Participant
- Posts: 2
- Joined: Fri Sep 10, 2004 11:12 am
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.
I set up job parameters in the Container, and where the container is called, i passed it the Environment variables from the calling job.