Posted: Wed Nov 01, 2000 11:42 pm
Trish,
Every one of our jobs has a DSN, User and Password parameter. Actually to be truthful, they have SourceDSN, SourceUser, SourcePassword, TargetDSN, TargetUser and TargetPassword parameters where "source" always refers to the source system and "target" refers to our data warehouse database.
Visible passwords should not an issue in Director if you use the encrypted parameter type. Much to my embarrassment, it took me a while to figure out that I had to double-click on these parameters to set a default password (if you want to).
As I mentioned in a recent posting, we have a function that compares the parameters of a calling job and an attached job which is about to be run. Where any parameter names match, it automatically sets the parameters of the job which is about to be run. We always call this function before calling DSRunJob.
So, all we have to do is type in the DSN, user, password for the top level job when we submit or schedule it and everything else happens automatically.
However, the other advantage we have is that only developers ever use Director anyway, and they already know all the passwords. We have a separate interface (home grown) for users to submit the few jobs that they are allowed to submit.
Hope this answers you question.
BTW ... it is good to see all the new members on this list. Until this last few days, I could probably count on one hand the number of people who have posted more than one message. (I wont name names for fear of offending
someone by omission
)
-----Original Message-----
From: Adams, Trish R (Compuware) [SMTP:AdamsTR@BP.COM]
Sent: Thursday, November 02, 2000 1:00 AM
To: informix-datastage@oliver.com
Subject: Database Security
Hi All,
Wondered if anyone had a strategy for database security, i.e., database name, username, password for jobs.
We dont want to hardcode these parameters in any of the jobs, and also do not want them visible in the director to anyone who monitors jobs. Also we are looking for a way to make them dynamic, so that jobs can be run on different Unix servers and access different databases (development vs. test vs. production).
So far, I have included a job control which contains code to read in a text file from the DataStage unix directory, which contains the database, and a valid userid and password for updating the database. Then as each job is added to the job control, I have set the input parameters to those read in from the text file. I wonder if there is an easier way to do this? Perhaps as a function or before subroutine. But I am having trouble understanding how to set the input parameters to values returned from a before subroutine or function.
Any thoughts or opinions?
Thanks,
Trish Adams
Compuware
*************************************************************************
This e-mail and any files transmitted with it may be confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in
error, please notify the sender by return e-mail, and delete this e-mail from your in-box. Do not copy it to anybody else
*************************************************************************
Every one of our jobs has a DSN, User and Password parameter. Actually to be truthful, they have SourceDSN, SourceUser, SourcePassword, TargetDSN, TargetUser and TargetPassword parameters where "source" always refers to the source system and "target" refers to our data warehouse database.
Visible passwords should not an issue in Director if you use the encrypted parameter type. Much to my embarrassment, it took me a while to figure out that I had to double-click on these parameters to set a default password (if you want to).
As I mentioned in a recent posting, we have a function that compares the parameters of a calling job and an attached job which is about to be run. Where any parameter names match, it automatically sets the parameters of the job which is about to be run. We always call this function before calling DSRunJob.
So, all we have to do is type in the DSN, user, password for the top level job when we submit or schedule it and everything else happens automatically.
However, the other advantage we have is that only developers ever use Director anyway, and they already know all the passwords. We have a separate interface (home grown) for users to submit the few jobs that they are allowed to submit.
Hope this answers you question.
BTW ... it is good to see all the new members on this list. Until this last few days, I could probably count on one hand the number of people who have posted more than one message. (I wont name names for fear of offending
someone by omission
![Smile :)](./images/smilies/icon_smile.gif)
-----Original Message-----
From: Adams, Trish R (Compuware) [SMTP:AdamsTR@BP.COM]
Sent: Thursday, November 02, 2000 1:00 AM
To: informix-datastage@oliver.com
Subject: Database Security
Hi All,
Wondered if anyone had a strategy for database security, i.e., database name, username, password for jobs.
We dont want to hardcode these parameters in any of the jobs, and also do not want them visible in the director to anyone who monitors jobs. Also we are looking for a way to make them dynamic, so that jobs can be run on different Unix servers and access different databases (development vs. test vs. production).
So far, I have included a job control which contains code to read in a text file from the DataStage unix directory, which contains the database, and a valid userid and password for updating the database. Then as each job is added to the job control, I have set the input parameters to those read in from the text file. I wonder if there is an easier way to do this? Perhaps as a function or before subroutine. But I am having trouble understanding how to set the input parameters to values returned from a before subroutine or function.
Any thoughts or opinions?
Thanks,
Trish Adams
Compuware
*************************************************************************
This e-mail and any files transmitted with it may be confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in
error, please notify the sender by return e-mail, and delete this e-mail from your in-box. Do not copy it to anybody else
*************************************************************************