scheduling - possible corruption issue

A forum for discussing DataStage<sup>®</sup> basics. If you're not sure where your question goes, start here.

Moderators: chulett, rschirm, roy

Post Reply
qt_ky
Premium Member
Premium Member
Posts: 2895
Joined: Wed Aug 03, 2011 6:16 am
Location: USA

scheduling - possible corruption issue

Post by qt_ky »

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.
Choose a job you love, and you will never have to work a day in your life. - Confucius
chulett
Charter Member
Charter Member
Posts: 43085
Joined: Tue Nov 12, 2002 4:34 pm
Location: Denver, CO

Post by chulett »

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.
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
johnboy3
Premium Member
Premium Member
Posts: 52
Joined: Fri Jun 19, 2015 2:48 pm
Location: Jackson, MS, USA

Post by johnboy3 »

We are not currently scheduling any jobs, but we may want to.

This seems pretty important to me, and I want to know the answer, too.
john3
john3
----------------------------------------------------
InfoSphere 8.5.0.2; DataStage 8.5.0.0; OS-RHEL 6.6; DB-Oracle Enterprise Edition 11g (11.2.0.4)
FranklinE
Premium Member
Premium Member
Posts: 739
Joined: Tue Nov 25, 2008 2:19 pm
Location: Malvern, PA

Post by FranklinE »

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
qt_ky
Premium Member
Premium Member
Posts: 2895
Joined: Wed Aug 03, 2011 6:16 am
Location: USA

Post by qt_ky »

Franklin, that is a great idea! I am going to test it. Thanks.
Choose a job you love, and you will never have to work a day in your life. - Confucius
ray.wurlod
Participant
Posts: 54607
Joined: Wed Oct 23, 2002 10:52 pm
Location: Sydney, Australia
Contact:

Post by ray.wurlod »

The parameter values entered when a job is (re-)scheduled are stored in one of the hashed files in the local DataStage repository.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Post Reply