DSXchange

I didn't ask you to change it to a table, just stated that the row counts show the number of rows that go down a link and not how many distinct rows get written, the behaviour is the same for hashed files and tables. The link itself doesn't know what the key is and what the target contains, i.e. it ...

Again, I should have read your post in its entirety, sorry. This sounds like the windows equivalent of a bad address in the program. This is occuring in your transform stage. Do you have nullable columns and are you sure you are handling them everywhere in that stage? Anything "tricky" hap...

zulfi, not using diferent config files in PX is like buying a Ferrari car but only using 1st gear.

Full log files can have impact on job runs, as Sainath has already mentioned, get rid of your warnings. If that isn't possible, at least use the message handler to not write those warnings to the log file and thus speed up performance and allow you to view the log from the director.

If you have a backup your best and quickest route to recovery is a complete cleanup and re-install of DataStage.

Are you sure you want to use a PX Routine (BuildOP) or just write a DataStage job?

This is a common question resulting from NLS and incorrect settings. Most likely your Oracle environment variable NLS_LANG is not set correctly at runtime. What value do you have and what NLS setting does your Oracle instance have?

Somewhere in your transform stage "TRANS1" your are performing a numeric function on a variable which contains a string.

n.b. This is a server job.

Use the built-in partitioning of PX; create a multinode configuration file and the default hashing algorithm then write to a fileset. Or write to a single sequential file then use the UNIX "split" command to create several files.

Let us just do one issue at a time. What sort of warnings are you seeing? Please cut-and-paste a sample to the thread.

Just for a comparison number - we have a job with about 500 stages in it (after optimization) that compiles on a big AIX machine in 0:45 to 1 hour on average. It has many transform stages. The number of CPUs on the box plays little role, as it seem that the compiler runs on only 1 CPU at a time and ...

I don't see how the &PH& contents could generatre this error, but before you try that, do a "reset" of your job and check the "...from previous run" entry.

The subject line in this thread is just as bad as the other thread with the same question; but at least there you already have a couple of responses. That thread should be used.

What method are you using in your Oracle stage - upsert or load? Does the job fail at the same place each time?
Also, you write

And we cannot view this job in director any more

then write

but I can view the job in designer and director

so I am unclear as to what you mean.

The term "binary" doesn't specify what type of binary file you have. Is it a COBOL type binary with COMP-3 and perhaps EBCDIC? Without that information nobody will be able to assist.