DSXchange

If you are on a Unix system then there is a file named .odbc.ini in the engine directory for DataStage. There will be a section named -

[ODBC]

and under this will be different parameters. Two of the parms are -

Trace=1
TraceFile=odbc.out or whatever might be on your system.

This is the name of the file where the trace output will be sent and if this is a simple filename then it will reside in the project the job was run from.

It sounds to me like (if you are Unix) that you do not have permissions to create or write to this file. If the Trace parm is set to 1 and you do not want tracing then set it to 0 (no need to stop and start services).

I would start here.

Regards,

Michael Hester

Michael -
what is this "DataStage Phantom"??? We see this on many of our jobs - though the jobs seem to complete successfully and the end result is as expected - I don't know what this "Phantom" error is.

Thanks

Hi,

"Phantom" is merely DataStage terminology for "background process". Each job, and each active stage in a job, may run as a separate background process.


There more details in the forum. Please search for it.

Ketfos

what is this "DataStage Phantom"??? We see this on many of our jobs - though the jobs seem to complete successfully and the end result is as expected - I don't know what this "Phantom" error is.

You should always try to understand why you're getting phantom errors because they might be altering your data in some subtle way that you're not picking up. Sometimes the phantom errors are nothing. Other times they're doing something to your data that you don't want to happen. I, personally, try to eliminate any phantom errors that I see.

Tony

As well as permissions, check for file system full where you're trying to write the trace file. ODBC traces can grow very large very fast!

Am afraid I am replying little late. What exactly is the warning message that is getting repeatedly printed? From that message at times we will be able to make some sense of the problme. One frequent reason for this kind of error is due to problem in a Routine that is being called (can be due to compilation problem, due to improper if/case construct coded in Routine with out giving any default value and blah blah) The exact treason can be found by looking at the exact warning message. A good exercise is to review all the routines your job is using.

Thanks & Regards,
Sarath

The message is contained in the original post
Unable to open ODBC trace file
This is highly unlikely to have been generated in a Routine unless that routine was using BCI function calls to connect to a database via ODBC.