DSXchange

Hi,

I have a senario like this, i am having an environment variable (Global Variable) say a, i have intial value say "A", during run time and based on some condition i want to change the value of the environment variable, i did this but the environment variable is not changing. Based on this environment variable i want to trigger the sequence by the custom - conditional <LHS> = <RHS>, i.e. a = 'B' then exeucte another job.

My first question is that can this be done, updation of environment variable. If not, can you given me another solution to get the value in the variable.

Regards,
Rajeev Prabhu

It is not permissible to change the value of a job parameter once the job has started. Job parameters are read into a static area when the job is started, and are ineligible to be changed.
Even if you can change the value of the environment variable upon which a job parameter is based, the value of the job parameter itself is not, and cannot be, changed.

You need to find an alternative strategy if you need something that may change during the execution of a job. Usually this will involve touching down to disk, either as a record in a hashed file with a constant value as its key, or to a dedicated text file (which will bottleneck a parallel job) or file set.

Follow-on question:

Is it possible to update a project-wide environment variable from within a job or sequence?

For example, suppose I would like to run a DS job early every morning that would set a user-defined environment variable, $COLOROFTHEDAY, dependent on the forecast high temperature read from an XML file obtained from an external provider. I want every job sequence in my project to be able to use this color. I'd rather not have to have every one of my jobs/sequences read in and parse the source file.

Can I do this in DataStage, and if so, how?

TIA,

tpb

It's definitely possible to change the value of an environment variable; it's unlikely that the change will be detected. Think about it in terms of processes; your job sequence is the parent process. You change the value in a child process (shell) via an Execute Command activity, for example. The child process exits; the change is lost. Child processes can not update their parents' environment variables, therefore the parent can not propagate the change to other child processes (activities). You will need to find a different propagation strategy.

Ray,

I can start Designer, open a job, create a new environment variable, close the job and exit from Designer. Later, I can go back into Designer, edit another job in the same project as before, and have access to the same environment variable.

This seems to indicate some sort of persistence at a level above any individual user or job process - perhaps at the DataStage server level? Are you saying that the value of the variable will not be maintained between jobs, even though its existence might be?

tpb

You cannot create an environment variable from Designer. The "Add Environment Variable..." button on the Parameters tab of job properties is really there to link an environment variable to a job parameter. Thus the name is a bit misleading. When you click the add button what you see is a list of project environment variables already set up through the DataStage Administrator. See the FAQ on project specific environment variables.

And when you migrate your job with that environment variable to other platforms or projects that have different values, your job still have the default value preserved -- over-riding what the project/system/universe/everything/42 values are.

This is why I advise all of my clients to not rely on project-level environment variables for anything outside PX-specific behavior (Such as hidden variables that tweaks the behavior of the jobs -- those are available as a list on your DataStage 7.5 documents.)

Thanks, those are informative comments.

But back to my original scenario, then:

banactp wrote: For example, suppose I would like to run a DS job early every morning that would set a user-defined environment variable, $COLOROFTHEDAY, dependent on the forecast high temperature read from an XML file obtained from an external provider. I want every job sequence in my project to be able to use this color. I'd rather not have to have every one of my jobs/sequences read in and parse the source file.

What's a good strategy to implement a project-wide value (such as 'color' in the eample above) that will change occasionally but should be treated as a constant parameter by individual jobs/users?

tpb

Hi Vincent,

vmcburney wrote:You cannot create an environment variable from Designer. The "Add Environment Variable..." button on the Parameters tab of job properties is really there to link an environment variable to a job parameter.

In 7.5, you can create an environment variables in designer also. when u click the add environment variable button, you see a window 'choose environment variable'. you can select new and create a new one.

Kris~

Create an external routine/script and use that routine to call DataStage jobs, passing values to that particular job variable.

T42 wrote:And when you migrate your job with that environment variable to other platforms or projects that have different values, your job still have the default value preserved -- over-riding what the project/system/universe/everything/42 values are.

This is why I advise all of my clients to not rely on project-level environment variables for anything outside PX-specific behavior (Such as hidden variables that tweaks the behavior of the jobs -- those are available as a list on your DataStage 7.5 documents.)

T42,

Our plan is to set project-level env vars and then pass them into job parameters at runtime using $PROJDEF as the default value. That's supposed to enable changes to the params without the need to recompile the jobs that use them.

Are there any drawbacks to this strategy?

Also, when you mentioned external routines/scripts, you were referring to routines/scripts outside of DataStage that would run dsjob with trailing parameters, right?

tpb

I am not quite clear on what you are trying to do.

When I am referring to Routines, I am referring to BASIC routines (yes, they can pass values to called PX jobs), and scripts are UNIX-level (Perl, KSH, C using the API, et cetera.)