Fault type is 11

SPA_BI · Post by **SPA_BI** » Sat Jun 14, 2008 5:45 am

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?

chulett · Post by **chulett** » Sat Jun 14, 2008 6:39 am

Well... you know what the first question is going to be. What changed? Anything that you are aware of, O/S or Oracle-wise, on your DataStage server? Patches, upgrade of the Oracle client, etc etc.

ArndW · Post by **ArndW** » Sat Jun 14, 2008 6:41 am

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?

SPA_BI · Post by **SPA_BI** » Sat Jun 14, 2008 4:08 pm

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.

ray.wurlod · Post by **ray.wurlod** » Sat Jun 14, 2008 4:10 pm

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.

SPA_BI · Post by **SPA_BI** » Sat Jun 14, 2008 4:35 pm

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.