Hello All,
Back to core Datastage development work after a gap of 1 yr and I find myself a bit rusty!! So need ur help.
I have a Parameter set with 3 different value files for 3 different regions, e.g. DEV, QA, PROD. And oh yes, the values are not static. They change. They have fileds like Delta record Timestamp etc.. Which gets dynamically generated before every new run.
Now when triggering the job through Unix, I can assign a value file name to the parameterset, like PARAMSET=DEV/QA/PROD.
So, my question is, when in sequencer, mapping this parameterset to a job activity, should I select the "Valuefile" name or just leave it "As-Predefined".
What is the difference between these 2 methods? And my other concern is, lets say I have selected the "DEV" value file from drop down. Do I have to change it to "PROD" and compile it once more before moving to PROD? That may not be a good idea!!
Parameter Sets
Moderators: chulett, rschirm, roy
-
- Participant
- Posts: 54
- Joined: Wed Oct 25, 2006 11:07 pm
- Location: Hyderabad
What I do is click the "Insert Parameter" button which then assigns the Parameter Set name, this then allows the values assigned in the sequence to be pushed down to the job. I would hope this is what the "pre defined" option is too but never bothered checking.
By this method, you should not have to re-compile when migrating, just specify the parameter set values file relevant to the environment.
I've never had a scenario requiring me to hard-code the values file but if you did, I would suspect that is the name it will look for at job run so any requirement to change that name would mean a job change.
Shouldn't take too much to test the cases out, ensure values are different between the actual parameters used and those in each values file and see what parameters go through to the job
By this method, you should not have to re-compile when migrating, just specify the parameter set values file relevant to the environment.
I've never had a scenario requiring me to hard-code the values file but if you did, I would suspect that is the name it will look for at job run so any requirement to change that name would mean a job change.
Shouldn't take too much to test the cases out, ensure values are different between the actual parameters used and those in each values file and see what parameters go through to the job