Curious how many others have run into this over the years and if anyone has a better solution...
When you schedule a repeating job from Director, it appears that the default parameter values are evaluated at the time of creating the schedule, and stored off to the side.... somewhere, instead of DataStage evaluating the default parameter values at the time of job execution.
Q1. Why is this the default behavior? Does anyone find this to be a good thing? There must be some benefit, not sure what. What I have noticed is that it leads to a lot of unexpected and unpleasant surprises followed by a lot of rescheduling.
Q2. Where are the scheduled jobs' parameter values getting stored?
Q3. Is it a known issue that encrypted parameter values (i.e. passwords) frequently get corrupted during the process of DataStage storing them somewhere at the time of creating the schedules?
We keep getting bit by this over and over. Scheduled jobs will sometimes abort due to invalid password. BUT, when you manually restart the same unchanged aborted sequence, not having changed or reset the password, the same job completes successfully. Hence, the password is actually valid.
I have searched other posts and pretty much only found the suggestion to try, try again, by deleting the schedule and recreating it. I think the implication is that perhaps one day you will get lucky and DataStage won't corrupt the password as it creates the schedule.
scheduling - possible corruption issue
Moderators: chulett, rschirm, roy
scheduling - possible corruption issue
Choose a job you love, and you will never have to work a day in your life. - Confucius
Wow, that's still going on? From what I recall, it does stash them somewhere so cron has access to them but don't recall the where. And I seem to recall a change to a schedule possibly triggering that so we would delete and recreate it instead. Sorry, got nothing else except this right now:
I think you can look at the crontab entry to see some of the secret sauce behind this... and guessing you'll need to ask support for the why of it. Goes back well before the concept of parameter sets and value files were introduced, FWIW.
I think you can look at the crontab entry to see some of the secret sauce behind this... and guessing you'll need to ask support for the why of it. Goes back well before the concept of parameter sets and value files were introduced, FWIW.
Last edited by chulett on Tue May 03, 2016 9:47 am, edited 1 time in total.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
Not sure if this helps: wrap the job in a job sequence that itself contains none of the parameters in the job to be executed. Seems to me that should force the default values be evaluated at runtime.
Franklin Evans
"Shared pain is lessened, shared joy increased. Thus do we refute entropy." -- Spider Robinson
Using mainframe data FAQ: viewtopic.php?t=143596 Using CFF FAQ: viewtopic.php?t=157872
"Shared pain is lessened, shared joy increased. Thus do we refute entropy." -- Spider Robinson
Using mainframe data FAQ: viewtopic.php?t=143596 Using CFF FAQ: viewtopic.php?t=157872
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact: