Page 1 of 1

Defining Global Parameters

Posted: Wed Sep 14, 2005 4:20 am
by maffan76
HI,
I have 3 projects DEV, Testing, Production. Now i want to define the global variables like DB_NAME, PASS etc. for each of it so that whne i have to move the job to Testing after Development then i sould change only these parameters instead of changing every where in the job.

What should be the best way to doing it?

Thanks in Advance.

Posted: Wed Sep 14, 2005 4:32 am
by Andal
You Should have used Environmental Variables while developing the Jobs.

Posted: Wed Sep 14, 2005 4:37 am
by adarsh shrinagesh
Hi

If all your jobs are connected in the Job Sequencer and ure running them from there - u wud only have to change the parameter value once for the Main Sequence( for all subsequent job sequences ).

Even otherwise if u've created wrapper scripts where u are reading the parameter values from a file in the job control where u have attached all the other jobs - u shud be changing it only once - in the parameter file that u create.

Posted: Wed Sep 14, 2005 4:38 am
by maffan76
But environment variable will conatin only 1 value at one point in time. so there are some jobs in Testing and some in Dev then it cannot have different DB names at any given time.

Posted: Wed Sep 14, 2005 4:40 am
by maffan76
any starting point how to develope the wrapper and read from parameter file.

Thanks.

Posted: Wed Sep 14, 2005 5:05 am
by Andal
Environmental Variable is common to project , so if you are having 3 projects you will be 3 DSParam files

Posted: Wed Sep 14, 2005 5:07 am
by maffan76
So whats the advantage and disadvantage of using Params vs Env Variables.

Posted: Wed Sep 14, 2005 5:12 am
by PhilHibbs
maffan76 wrote:So whats the advantage and disadvantage of using Params vs Env Variables.
If you are using DS 7.0.1 then there is effectively no difference. On later versions (I'm not sure if you need 7.1 or 7.5) you can apparently use a value of $PROJDEF or $ProjDef or something like that, and it will pick up the parameter value from the project environment.

Since I can't make use of this feature, or of parameter files, I pass all my code through a Perl script that changes the parameters (root directory, server names, user names, passwords, ABAP program names, etc.) appropriately depending on whether it is going from Dev to QA or from QA to Prod.

The Perl script also makes a few other checks, such as checking that sequential files have column names, checking that all parameters are correctly included, listing ABAP program names for SAP jobs, listing external SQL files for EDA stages, and listing all the mkdir commands that may be needed to create the QA or Prod directory structures.

Posted: Wed Sep 14, 2005 6:52 am
by adarsh shrinagesh
Hi

I'm a little confused - Could u please elaborate on the use of Envornment variables witihin a Job.

Posted: Wed Sep 14, 2005 7:39 am
by PhilHibbs
adarsh shrinagesh wrote:Hi
I'm a little confused - Could u please elaborate on the use of Envornment variables witihin a Job.
In the Job Properties dialog, on the Parameters tab, you can click the "Add Environment Variable" to add an EV to the job. You can add EV's to the project in the DataStage Administrator application.

In 7.0.1, these are effectively just easy-to-use templates for adding standardised parameters to a job. The parameter is used as #$X# instead of #X#, and you can't change the prompt, but other than that they are just parameters that are stored in the project. If you change the EV's default value in the project, that does not affect any jobs that use the EV as a parameter.

Someone else will have to elaborate on the usage of $ProjDef as I have never used it since it doesn't work in 7.0.1.

Posted: Wed Sep 14, 2005 7:52 am
by maffan76
so ENV VAR will be used as $VAR or #$VAR# ? and secondly can i concatenate the ENV VAR with fixed string value
for example i want to store the drive letter in ENV VAR and concatenate it with the Folder name e.g. $VAR\folder os will it be translated as C:\folder

Posted: Wed Sep 14, 2005 4:39 pm
by vmcburney
I am on a project where we moved from environment variables ($ENV) across to project variables ($PROJDEF). The good thing about environment variables is that you can share them with other applications. For example cognos cube builds or ftp scripts. However we had a dev environment that was also used for testing and trying to keep track of which user had what environment variables was becoming difficult. It also exposes passwords as plain text.

With project variables we are able to defined a set of variables for a project and have a better idea of the scope of those variables.

See the entry in the FAQ forum on this site or the modifiable version over at ittoolbox.
http://wiki.ittoolbox.com/index.php/HOW ... _variables

So it really depends on what you are more comfortable with. There is also the option of storing parameters in an ini style text file or in a database table and writing a routine to retrieve them and pass them to sequence jobs. The new set variables stage in sequence jobs makes this easier then it used to be.