Job Crash

alfordk9 · Post by **alfordk9** » Mon Dec 29, 2003 3:45 pm

I checked all the job names and they seem to be there. So I went into the jobs and saw that the job that the control says only started actually had finished and never got read as such from the job control. My co-worker is still investigating by going job by job. Maybe it's our customized version of the job control. I wasn't aware that we had one. (Still fairly new here)

kcbland · Post by **kcbland** » Mon Dec 29, 2003 3:53 pm

alfordk9 wrote:I wasn't aware that we had one.

Yes you do, and I think I know who customized it for you. The API that is blowing up is a DSGetJobInfo

121006\2003-12-26 21:32:26\3\\6\Batch::MasterControl..JobControl (fatal error from DSGetJobInfo): Job control fatal error (-99) (...)

What would be helpful is if you clicked on this specific message and pasted the contents onto the forum. It will tell you the job that is generating this message. The API blew up because the job handle is invalid.

alfordk9 · Post by **alfordk9** » Mon Dec 29, 2003 4:05 pm

Unfortunately that error message is so far back i had to pull what I pasted from the archive of our logs. I can't double click in it at this point in time. I am going to wait to wait till it crashes again. Arrgghhhh

alfordk9 · Post by **alfordk9** » Mon Dec 29, 2003 4:07 pm

These are the last few message from the MasterControl log this is the best I can do right now (unless you know some other way to get back those old log files)

22195\2003-12-26 21:30:58\1\\6\Batch::MasterControl..JobControl (RunBatch): SendMail output: (...)
22196\2003-12-26 21:30:58\1\\6\Batch::MasterControl..JobControl (Batch::MasterControl): Batch ran OK
22197\2003-12-26 21:30:58\1\\6\Batch::MasterControl..JobControl (Batch::MasterControl): *** <END> Unload Setup Tables <END> ***
22198\2003-12-26 21:30:58\1\\6\Batch::MasterControl..JobControl (Batch::MasterControl): *************** <START> Batch::RunJobEngine <START> ***************
22199\2003-12-26 21:30:58\1\\6\Batch::MasterControl..JobControl (GetSystemType): System Type = NT
22200\2003-12-26 21:30:58\1\\6\Batch::MasterControl..JobControl (RunBatch): Batch Configuration Data: (...)
22201\2003-12-26 21:30:58\1\\6\Batch::MasterControl..JobControl (RunBatch): Job list and maximum run times: (...)
22202\2003-12-26 21:30:58\1\\6\Batch::MasterControl..JobControl (GetParameterArray): Loading parameters from file: C:\Datastage\production\work\parameter\parameters.ini
22203\2003-12-26 21:30:58\1\\6\Batch::MasterControl..JobControl (GetParameterArray): Parameters and Values loaded: (...)
22204\2003-12-26 21:30:58\1\\6\Batch::MasterControl..JobControl (RunBatch): Batch Job parameters and values loaded: (...)
22205\2003-12-26 21:30:58\1\\6\Batch::MasterControl..JobControl (RunBatch): SendMail output: (...)
22206\2003-12-26 21:31:02\7\\6\Batch::MasterControl -> (Batch::RunJobEngine): Job run requested (...)
22207\2003-12-26 21:31:02\1\\6\Batch::MasterControl..JobControl (DSRunJob): Waiting for job Batch::RunJobEngine to start

roy · Post by **roy** » Tue Dec 30, 2003 3:33 am

Hi,
Ray, doesn't the generated code from adding a job in a control basic job cover that?
I think this goes something like:

Code: Select all

 hJob = DSAttachJob(....)
if Not(hJob) then ....

isn't that enough?

kcbland · Post by **kcbland** » Tue Dec 30, 2003 7:02 am

Code: Select all

hJob = DSAttachJob("Job_Name", DSJ.ERRNONE) 
JName = DSGetJobInfo(hJob, DSJ.JOBNAME) 
If JName = DSJE.BADHANDLE

If you look at DSAttachJob, the second argument is what the API is supposed to do if it fails. Your choices are DSJ.ERRFATAL (BLOW UP) or DSJ.ERRNONE (Continue on your merry way).

What Ray is suggesting is to use ERRNONE and then try to use the handle in another API, and then see if the return value from that other API is that of a bad job handle. Kind of silly, but I guess it will work. I'm going to verify this, because it will make things more robust.

What I have done is added validation logic to the core job control library that verifies that every job exists and is in a compiled state (otherwise it can compile it). This reduces the possibility of an AttachJob failing, but I want the API to return a predetermined value if it can't attach. If you read the docs, it says that a handle can be any value, numeric or text. There's no way to return a error value. The API takes care of BLOWING UP the job if it can't attach. This is terrible, APIs shouldn't be exit points. I have the same criticism for DSLogFatal, once you call it, control never returns.

Terrible.

alfordk9 · Post by **alfordk9** » Tue Dec 30, 2003 7:34 am

So if I understand what you guys are saying correctly you want me to add that error handling before it attachs to each job so that if the attach fails the job continues on to the next process and logs the error? I have to think about that because depending on the job if it were to fail it would still cause severe errors in our end data validation. So I guess the real desired end result would be that each job committ as it is supposed to so we could be balanced.

kcbland · Post by **kcbland** » Tue Dec 30, 2003 9:12 am

Whoa, this isn't a variant of my stuff. I see pieces of my logic, it looks like my stuff was cannibalized for a few parts, but the whole is not mine. Some chunks of code are from the library, even the name is from an old version, but that's where it ends.

I claim NO association to this routine.

Anyway, trying to digest it now...

roy · Post by **roy** » Tue Dec 30, 2003 10:09 am

Hi,
I actually ment to ask whethere the "if Not(hJob)" is good enough to check for DSAttach(...) success.
I used it fairly well several times, just didn't use Abort or DSLogFatal() to terminate my job, instead I used other routines/subroutines etc' to make notices and notifications and went on with my logic.
my code never crashed for using the default DSAttach(...), as it comes when you add a job to a basic code from the drop down job menu.

now i wonder if anyone will get to read this post since this is turning to be quite a long post lol, even if it went a stray from the original post.

kcbland · Post by **kcbland** » Tue Dec 30, 2003 11:31 am

roy wrote:Hi,
I actually ment to ask whethere the "if Not(hJob)" is good enough to check for DSAttach(...) success.

Nope, read the BASIC manual. It states that any value can be returned. Your logic assumes that a 0 return code is an invalid handle, which the manual says is not true.

ray.wurlod · Post by **ray.wurlod** » Tue Dec 30, 2003 4:15 pm

kcbland wrote:
roy wrote:Hi,
I actually ment to ask whethere the "if Not(hJob)" is good enough to check for DSAttach(...) success.
Nope, read the BASIC manual. It states that any value can be returned. Your logic assumes that a 0 return code is an invalid handle, which the manual says is not true.

This is a gripe I have with generated Job Control code, which directly contravenes the advice in the manual, and uses Not(hJob1) as the test for DSAttach(). And why I prefer using an innocuous function like DSGetJobInfo(), which can return DSJE.BADHANDLE.

bdixon · Post by **bdixon** » Sun Jan 04, 2004 5:58 pm

I had a similar problem to this and I found that our virus scan was conflicting with datastage... it seemed to be locking some files that datasatge needed causing it to crash at different times. Would might want to turn your virus scanner off and see it if crashes any more. It this works then you might want to reconsider when/how you do your virus scans / updates.