Hi there,
I've been reading the forum regarding error of "Fault type is 11", and tried out some of the solutions such as altering the buffer and timeout figures, ensuring the job doesn't aort after a single warning, and killing off phantoms.
My job still aborts when I try to run, and gives the following log when reset:
DataStage Job 1123 Phantom 19837
kgefec: fatal error Abnormal termination of DataStage.
Fault type is 11. Layer type is BASIC run machine.
Fault occurred in BASIC program JOB.892755921.DT.1427560310.TRANS1 at address de.0
This is a job which has run for years without problems, and suddenly wont complete. Data is being loaded from an Oracle OCI 8 stage to sequential file, via a transformer. Strangely, although the job aborts the data seems to make it to the sequential file, allowing proceeding jobs to be manually run.
Any ideas?
Fault type is 11
Moderators: chulett, rschirm, roy
Fault type is 11
from SPA_BI
Can you recompile the job and post the actual error address, "de.0" is not a valid hex offset. What non-trivial things do you do in your transform stage?
<a href=http://www.worldcommunitygrid.org/team/ ... TZ9H4CGVP1 target="WCGWin">
</a>
</a>
nothing that I'm aware of in the week since this datastage job last ran. I will confirm with unix support as to whether they have done anything to the unix server tomorrow though (usually they post around notification if they do though).
Curiously, about 5 hours after attempting to re-run this job, and ultimately resetting it, the log of the same job registered an oracle temp segment error (ORA-01652). Curious that this error didn't occur when the job was running, only many hours after being aborted and reset. I've also raised a case with our DBA's to see if the temp space allocated is adequate or changed.
Curiously, about 5 hours after attempting to re-run this job, and ultimately resetting it, the log of the same job registered an oracle temp segment error (ORA-01652). Curious that this error didn't occur when the job was running, only many hours after being aborted and reset. I've also raised a case with our DBA's to see if the temp space allocated is adequate or changed.
from SPA_BI
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
I suspect that 0xde is the address, the "." is punctuation indicating the end of that sentence in the error message and the final "0" is spurious.
Therefore a VLIST of the generated Transformer code would reveal what instruction occurs at addres 0xde and the corresponding source statement.
Therefore a VLIST of the generated Transformer code would reveal what instruction occurs at addres 0xde and the corresponding source statement.
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.
recompiling doesn't provide more error information (the complete address never displays in the log).
The transform just loads data to the sequential file, and generates an extra column called AGGREG_DATE using the following input Oconv(DATE(),"DYMD[4,2,2]"):" ": Oconv(TIME(),"MT"):":00"
Sorry Ray, can't read all your advice at the moment. Let my premium membership lapse but reapplied for it just now.
The transform just loads data to the sequential file, and generates an extra column called AGGREG_DATE using the following input Oconv(DATE(),"DYMD[4,2,2]"):" ": Oconv(TIME(),"MT"):":00"
Sorry Ray, can't read all your advice at the moment. Let my premium membership lapse but reapplied for it just now.
from SPA_BI