Hi,
I have a simple extract job which exacts from a DB2 table. Recently there were some issues on the DB2 side and hence the queries were not processed properly.
All the server jobs that ran extracts failed with the fatal warning 'No FCM buffers available'. The same warning also cropped up in the PX job. However, the job did not fail and completed successfully!
Could someone explain this behaviour and how do I get the job to fail when a fatal warning comes up? Thanks!
Fatal warning but job does not abort
Moderators: chulett, rschirm, roy
Fatal warning but job does not abort
Joel Satire
The job should fail, unless the warning is such that it occurred and then was corrected automatically upon retry. Note that the message was a "warning" in your PX job. Was the result from the PX job correct or not? If not, then this is certainly a bug.
<a href=http://www.worldcommunitygrid.org/team/ ... TZ9H4CGVP1 target="WCGWin">
</a>
</a>
I have the EXACT same issue! We have several jobs where, in the log, there are either warnings or fatal errors and yet the job status is "Finished" (i.e. OK, i.e JobStatus=1).
This is NOT acceptable to us. Looking at the status screen in director, everything looks great. We have to individually open each of the logs to review to see if there are any fatal errors or warnings.
I hope you find out what is causing this because I have looked it up several times in the past without finding a solution.
Every time I bring up the problem, people focus on the error or warning and NOT on the fact that the log does not match the jobstatus.
For us, it typically happens in jobs with ODBC connections, but we've seen it in other jobs as well.
This is NOT acceptable to us. Looking at the status screen in director, everything looks great. We have to individually open each of the logs to review to see if there are any fatal errors or warnings.
I hope you find out what is causing this because I have looked it up several times in the past without finding a solution.
Every time I bring up the problem, people focus on the error or warning and NOT on the fact that the log does not match the jobstatus.
For us, it typically happens in jobs with ODBC connections, but we've seen it in other jobs as well.
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
This is one area where parallel jobs are different from server jobs. A different mindset is needed.
Parallel jobs can finish with a status of "Finished" even though there are stages that generate "fatal" errors. This is because the exit status is that of the conductor process.
You can detect (in an after-job subroutine or in a parent sequence) whether there were any warnings/errors in the log, and do something about it.
Parallel jobs can finish with a status of "Finished" even though there are stages that generate "fatal" errors. This is because the exit status is that of the conductor process.
You can detect (in an after-job subroutine or in a parent sequence) whether there were any warnings/errors in the log, and do something about it.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
This is one area where parallel jobs are different from server jobs. A different mindset is needed.
Parallel jobs can finish with a status of "Finished" even though there are stages that generate "fatal" errors. This is because the exit status is that of the conductor process.
You can detect (in an after-job subroutine or in a parent sequence) whether there were any warnings/errors in the log, and do something about it.
Parallel jobs can finish with a status of "Finished" even though there are stages that generate "fatal" errors. This is because the exit status is that of the conductor process.
You can detect (in an after-job subroutine or in a parent sequence) whether there were any warnings/errors in the log, and do something about it.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.