customized groupings of environment variables

[admin]

>While this functionality does not appear to exist through the Adminstrator
>tool, the DSParams file contains comments which document how to create
>these subgroupings. Once you change the DSParams, all of the environment
>variables - including the subgroupings - can be maintained through
>Administrator.
>
>I've tested my configuration with few jobs and not run into any problems,
>but I'm not whether this type of "tweak" would be supported Ascential so
>I'm nervous about trying to deploy this type of configuration.

It is not officially supported, so it is not advised to do it unless you are
willing to go back to the old way when Ascential decides to change this.

However, let me take a moment to steer you away from using the Project-level
Environment variables for your company-specific tasks. Do not do it. DO
NOT DO IT. Please.

1. The values provided for those variables does not change when you migrate
your job between projects. So if you have a DEV project pointing to
OracleDEV database, do not expect the job that is migrated to your PROD
project to point to OraclePROD database without manually modifying the job
itself.

2. It create troubles on the command line. $ is a special character in
UNIX. So if you try to do a dsjob run, you have to remember every time to
put a \ next to the $. Trust me, people forget that all the time. ALL THE
TIME.

3. Growth of naming convention. One variable pointing to one database,
another variable pointing to another database. Everything going everywhere.
And still #1 does not apply. Keep it simple - ORACLE_DATABASE,
ORACLE_USERNAME, ORACLE_PASSWORD.

4. DataStage Engine depends on these variables. So if you put something
like $APT_NO_ORACLE_WIDGET, you are NOT guaranteed that this is YOUR own
variable. DataStage may see that and go, "Hmm, hey! That turns on
something within my engine! Yay!" In the end, it gives you unpredictable
results that bounces your job all over the place, and give people nightmares
for weeks (especially your managers.) There is no guarantee that not using
$APT_ will get you home free.

5. You obviously know about DSParams. But if you are managing 75+ projects
over several servers (and platforms), updating all the environment variables
would be a pain in the butt for anyone administrating DataStage.

6. People who want to be lazy and do the point-and-click are shaving... 30
seconds off their development time. Okay, maybe upward to... 5 minutes. As
any experienced developer would tell you -- when you are on a level that is
'good enough' -- using DataStage that shaves hours and days off your
development time -- don't push it.

There are more that I have written down in my critique on using
Project-level environment variables for your own job's variables. There is
a reason Ascential called it ENVIRONMENT variable. It is for the DataStage
environment only.

If you want to manage parameters, use a better tool. One suggestion is
this:

http://www.datastagexchange.com/PM/

(Parameter Manager for DataStage)

-T.J.

_________________________________________________________________
There are now three new levels of MSN Hotmail Extra Storage! Learn more.
http://join.msn.com/?pgmarket=en-us&pag ... l/es2&ST=1

_______________________________________________
datastage-users mailing list
datastage-users@oliver.com
http://www.oliver.com/mailman/listinfo/datastage-users