DSXchange

That would be an external as in string format (not a DATE), use TO_CHAR() with the appropriate mask in your source SQL into a Varchar field.

Still questioning the alleged need for these 'readonly' jobs to be edited...

I don't know what it used to say before your edit but the new version isn't all that much better.

No. You've seen what DataStage considers "formatted" output and if that's not what you want you should not enable that option. Keep in mind that formatting like that is only for peoples and no XML reader will care or need any formatting, so most applications don't bother with it. If someho...

PX is a completely different beast and built from the ground up for parallelism. Not that you can't still get into trouble with PX and partitioning but it's really an "apples to oranges" comparison to the kind of parallel processing you can make a Server job do. IMHO. Perhaps Ernie or Ray ...

Server isn't strongly typed like PX so there isn't much in the way of conversion functions to be had - or needed. Never mind the fact that flat files have no data types, only 'character' fields when you get right down to it.

I don't think you can get full details like you want from the 'Summary' function, have you tried the 'detail' version - DSGetLogEntry, I believe?

OK... what is in the log for that job? Anything out of the ordinary? Does it seem like the job should have run to completion according to the log?

You don't. You take what you need from the five 'base' tables one at a time.

Clarify what you mean by "stopped status". If you mean literally that, it could simply mean that someone clicked on "Stop" from the Director for that job.

What settings are you using in the source DB2 stage? What partitioning is in use in the job? As noted, you seem to have it set to 'Entire' so that each node gets a complete copy of the selected data.

How can anyone help without any details?

What kind of "load" is this? What are you doing with these 23M records on a daily basis? How many nodes? (etc,etc) Some improperly designed loads by their very nature will take longer and longer to run, hence the question.

Yes. Technically, for "post version 7" support as in support for version 8 you really need to involve support for issues of this nature.

First suggestion is always going to be to search and since you didn't mention doing that - see if an Exact Match search for "Unable to use a record for update" helps at all.

The legacy 'Universe' repository is alive and well and functioning the same as it always has in 8.x, it's just that they have added the XMETA layer "on top" of that, so to speak.