DSXchange

Must have or we wouldn't be here. :wink: I don't know what exactly is all involved, not having DB2 access, but you need to configure DataStage for DB2. I'm sure it's documented in the Installation and Configuration Guide and probably the specific docs for the DB2 stage as well. And then there's that...

... with still the same answer I posted yesterday.

Unfortunately, that advice no longer applies in the 8.x world, you need to do something different. I don't know what, but I do know you can no longer take that approach.

Both methods can require you to tell it where to start from. The Surrogate stage handles any partitioning requirements automatically, you can read about that in the Parallel Job Developer's Guide pdf documentation. From what I understand, 8.x adds a 'state file' option in additional to using a job p...

For that, you'd need to select the max value and pass that into the job each time so it knows where to start. Why not use the Surrogate Key stage instead?

So... you upgraded to 8.1 and it stopped working? You installed 8.1 and it doesn't work?

Doesn't answer the question if the header record itself has the correct number of pipe delimiters in it. DataStage seems to think it doesn't.

Actually, I should have asked about your header record. It still gets read and parsed, just not passed out so "row 1" is your header record, not the first data record.

And you are positive there's no extra pipe in that first data record?

To 'generate unique ids' perhaps a Surrogate Key stage could be used. You'd have to explain just how 'unique' this id needs to be, however.

That 'some kind of character' is a CR, the first half of the 'DOS style' line termination CR/LF pair. UNIX only uses a LF so it sees the CR as data. However, I don't see how changing that option solved your problem.

Is row 1 a header record?

You're wrong, hence the error. DSJobInvocationId is only valid in a multi-instance job and returns the value of the Invocation Id. You'll need to generate this 'integer value' some other way.

You can only "replace" from the last column towards the first column with no "error" columns between them. So while... ColA Error ColB Error ColC Replace ColD Replace Is legal, ColA Error ColB Replace ColC Error ColD Replace Would not be and would generate your error for ColB.

There is no "import selected from the command line".

Why the heck would you need a Perl script to run an orchadmin command? Just... run it, in a perfectly normal script or batch file.