DSXchange

Ok... one of three questions answered.

So... use a Transformer?

OK, OK... not "only only".

Right... you can use Convert() to strip any CHAR(10) values from the last field or leverage "dos2unix" in the Filter option when reading the file.

Exactly. Simply note the type in each Sequential File stage. And, as Ray notes, understand that the Display size controls the fixed-width column size.

Also, the only real "UNIX command related to DataStage" I can think of is dsjob. Read about it in either Developer's Guide pdfs in the Command Line Interface chapter.

Too late. Argh... deleted my reply. Duplicate posts actually.

I know we've seen that gdb/sed message posted here before - do an Exact search for "check that 'gdb' and 'sed' are installed" and see if any of those posts help.

That's just your normal Windows/UNIX record delimiter tomfoolery and is a sign that whomever transferred the file didn't do it properly. UNIX uses a single LineFeed character while Windows uses two characters - a CR/LF pair. A Windows or "DOS" style file on a UNIX server will show the CR as a last b...

Nicole - please start your own post. Your issue is completely different from the one being discussed here.

It's actually DS_AUDIT, I do believe.

There's a client-side patch for that. Ask your support provider about eCase 62595.

cool wrote:if job status ok then i should display success in output else fail

Sorry, what? "Display success"?

DataStage has "oops tracing"? Cool.

And why in the world use "custom" sql for something as simple as this? My rule? Only when absolutely needed, otherwise the stage generates the SQL.