A somewhat odd question about parameters and environments

[StefL]

I'm implementing a number of jobs on a pretty 'standard' working environment. I.e there's a development server, a test server and a production server (well, the production server's not there yet but it will be in a while).
Jobs are moved between the servers using Version Control, in a standardized way.
In order to allow for different connect strings to databases I've implemented them as parameters using Project Environment Variables in the job sequences that I use to call the actual jobs doing the data shuffling. I.e the job sequences have Environment Variables defined, using the $PROJDEF option to always read the current value in the repository, and use these values as in-parameters to the server jobs.
This means that all that needs to be done when moving a job from Dev to Test or Prod is to set up the proper Project Variables on Test or Prod and set whatever values needed, and then all jobs will get the right values as needed.

I can't see that there could be a more practical way to solve this, and does anyone disagree with me in that this would be the 'best practice' way of doing things?

The reason I ask is that I've had requirements laid on me for another solution that I would not recommend to implement and I'd like to know that what I'm recommending is the standard and most practical solution.

[ArndW]

Stefl,

first off - the question isn't really an odd one; it is a subject that most of us have come up against in the past and/or will most likely encounter in the future. The most important part of ensuring a smooth transition of jobs between the environments is parameterization - without that you are in trouble but you have taken care of that at the outset.

There are numerous ways of ensuring that the runtime values of the parameters are set to that required of the environment; the solution you have decided upon will work for your setup because of the way you are naming your projects and/or database environments and schemas. This might not work for other implementations, where alternate methods would need to be used.

I see no reason to change how you have done it, it is simple, understandable and maintainable.

[vmcburney]

This is exactly what I am implementing at the moment, replacing a Unix script based system, the main reason I chose it is that it encrypts the password parameters in all places and it lets us use "View Data" in our development environment. Passwords appear as encrypted **** strings when they are set in the DataStage Administratorand in the DataStage jobs and job stages, they appear as junk text in the DSParams file and all job logs. Other then using Parameter Manager I don't know of an easier way to fully secure password parameters.

There are other good options for managing parameters such as loading them from tables or files but unless you have the routines to do this already written you wont find an easier way then project specific environment variables. This has only been the case for a couple releases now, the addition of better job sequence functionality and better handling of environment variable defaults makes this approach viable. For example we probably couldn't do it this way if we didn't have the UserVariable activity stage to set our dynamic parameters such as dates and process ids.