Parameter Set Change - Compile Jobs
Moderators: chulett, rschirm, roy
-
- Participant
- Posts: 9
- Joined: Fri Jun 01, 2007 12:14 am
Parameter Set Change - Compile Jobs
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
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
karun
-
- Participant
- Posts: 9
- Joined: Fri Jun 01, 2007 12:14 am
-
- Participant
- Posts: 9
- Joined: Fri Jun 01, 2007 12:14 am
-
- Premium Member
- Posts: 291
- Joined: Wed Sep 26, 2007 11:23 am
- Location: Madrid, Spain
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.
"It is not the lucky ones are grateful.
There are the grateful those are happy." Francis Bacon
There are the grateful those are happy." Francis Bacon
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.
The middle of every successful project looks like a disaster -- Rosabeth Moss Cantor
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.
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.
Last edited by asorrell on Thu Jul 25, 2013 1:38 pm, edited 1 time in total.
-
- Participant
- Posts: 40
- Joined: Thu Apr 17, 2008 1:52 pm
- Location: Huntsville, AL
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
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,
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,
- james wiles
All generalizations are false, including this one - Mark Twain.
All generalizations are false, including this one - Mark Twain.
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
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.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.