sometimes the job fails it seems i have to recompile the job in order to rerun it
No, you don't. You need to Reset the job, not recompile it.
I have found at least two instances where a job had to be re-compiled because the reset mechanism didn't work. One of them was a few years ago, and I think the problem was something to do with a hashed file having been deleted so it couldn't do one of the reset operations. The other was today, we had to abort an EDA extract job (we use the IBI EDA plug-in stage), and resetting the job didn't work, we had to re-compile it in order to get it to run again.
Perhaps something specific to that plug-in, I don't recall ever having a time where a reset didn't work and I had to fall back on a recompile. For whatever that is worth.
-craig
"You can never have too many knives" -- Logan Nine Fingers
You need to put a little effort into figuring this out. Add some calls to DSLogInfo() after each step. The second step will fail if the first is not successful and you need to check to see that the handle returned is validbefore proceeding to the next step. Don't write code that lives in fantasy land and assumes that everything works every time. Add some error handling steps in there, log enough information to help you figure out what in the heck is happening.
Last edited by chulett on Mon Feb 23, 2009 10:25 pm, edited 1 time in total.
-craig
"You can never have too many knives" -- Logan Nine Fingers
I typically use a "harmless" function (get job name) right after the call to DSAttachJob() function. This is a quick way to test whether the attach succeeded; if it didn't the harmless function returns DSJE.BADHANDLE.
hJob1 = DSAttachJob(<JobName>, DSJ.<errorlevel>)
If Not(hJob1) Then
<Error handling here>
End Else
hJob1 = DSPrepare(hJob1)
<etc>
End
Rather than explicitly testing the validity of the handle, make sure the returned handle isn't zero. Figured if it was good enough for Ardent / Ascential / IBM / whomever...
-craig
"You can never have too many knives" -- Logan Nine Fingers
It wasn't good enough. Their manuals explicitly stated that you should never make any assumption about the data type of the job handle variable - you should treat it as opaque. Then they go and break their own rules.
When IBM do change it's data type from integer row number in internal table of job handles to a true pointer, then you'll ALL be ruined!!!!
Ah hahahahahahaha!!!!!
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
I tried something like this and the job wouldnt run:
and the job would just freeze
hJob1 = DSAttachJob("AuxTime".DSJ.ERRFATAL)
If NOT(hJob1) Then
Call DSLogFatal("Job Failed: AuxTime","Job")
Abort
End
ErrCode = DSRunJob(JJob1, DSJ.RUNNORMAL)
Status = DSGetJobInfo(hJob1, DSJ.JOBSTATUS)
Something like this or this exactly? You need a comma between the job name and DSJ.ERRFATAL, not a dot. And you've got "JJob1" in the DSRunJob call rather than "hJob1". Details are important, you know.
-craig
"You can never have too many knives" -- Logan Nine Fingers
this is what i put in the job control and the project just started but wouldnt run
hJob1 = DSAttachJob("AuxTime",DSJ.ERRFATAL)
If NOT(hJob1) Then
Call DSLogFatal("Job Failed: AuxTime","Job")
Abort
End
ErrCode = DSRunJob(hJob1, DSJ.RUNNORMAL)
Status = DSGetJobInfo(hJob1, DSJ.JOBSTATUS)