Parameter Set Change - Compile Jobs

[karunakar.ds]

Hello,

I have changed the Database Password value in one of the Parameter sets and ran a job which is using the same Parameter set but the job got aborted as it considered the old password. However, the job ran fine when I compile and re-ran job as it took the latest password which is updated in the Parameter set.

1) Do we need to compile the jobs whenever any changes done in the Parameter Sets?

2) Is there any way or method that to avoid compiling the jobs whenever any changes done to the Parameter Sets?

If I am not wrong whenever we change the environment variables in the Administrator tool we don't compile the jobs as the jobs pickup the latest details during the run time.

Thanks,
KK

[chulett]

From what I recall, older 8.x releases had this issue but it has since been corrected. What release / hot fix are you running?

[karunakar.ds]

From what I recall, older 8.x releases had this issue but it has since been corrected. What release / hot fix are you running? ...

I am using Datastage 8.5. It looks like they haven't fix this issue in 8.5. Is there any patch for this issue?

[chulett]

Perhaps it was reintroduced. Regardless, that would be a question for your official support provider.

[karunakar.ds]

Thats true. However, I just want to check with you if you heard anything about that patch.

[manuel.gomez]

I have experienced those problems too with version 8.1 and 8.5

[BI-RMA]

It is possible, however, to use values like $PROJDEF in Parameter Sets, at least starting from Version 8.1 . This makes it possible to change the password within Administrator on project-level without having to recompile the job after the change.

[haylo75]

The recompilation required behavior continues through 9.1 Fix Pack 1. Given the versions this issue now spans, it's hard to believe it isn't by design. The environment variable workaround works but is clumsy, as replication of variables inside Parameter Sets must occur. Our workaround is also clumsy, which is to force the use of Value Files since I've verified they are read at runtime.

[asorrell]

I don't understand why you say using environment variables is clumsy. We use parameter sets all the time which contain environment variables with default values set to $PROJDEF. The parameter set is used in the job sequence and also inside the jobs.

Any time we change an environment variable the change is immediately picked up during the next job run.

This has enabled us to migrate jobs from environment to environment and get new settings (schema names, etc) without recompiling. It also allows us to update password environment variables and have all the jobs use the new password without re-compilation.

[josh.guffey]

Just use the string $PROJDEF in your parameter set for the password value. It will automatically resolve changes from the administrator client. Job recompiles are not necessary. It was also discussed here

[SURA]

To overcome this issue i changed the parameters value to get it from the file. Passwords alone from Admin. Now it is fine for me!

[jwiles]

This has been mentioned in other threads in the forum but bears occasional repeating for those searching: ParameterSet default values are included in the job at COMPILE time. Therefore, hardcoding default values for parameters that will change value over time (such as userids and passwords!) is never a good practice as it forces you to recompile your jobs when those values must change.

The solutions: Follow Andy's example of using environment variables and $PROJDEF for the default value and/or use ValueFiles to hold the values and pass the ValueFile name at runtime.

Regards,

[ray.wurlod]

Another approach that I've seen at some sites is not to use Parameter Sets in server or parallel jobs; only to use Parameter Sets in sequences. In the Job activity the local parameter is fed its value from the parameter from the parameter set. Consistent parameter naming methodology is key to keeping this solution easily maintainable.