DSXchange

That is what it should be doing. I haven't worked with Teradata and think that this might a problem specific to that stage.
Go into the attributes for that column and explicitly set the default value for the column to NULL and see if that makes a difference.

How many bytes are expected per row? I can only imagine this type of error if you exceed the APT config setting for $APT_MAX_TRANSPORT_BLOCK_SIZE which defaults to 1048576. Or perhaps your jobs's ulimit settings are particularly restrictive.

The implications of being able to use separate itags for the engine in past releases (before V8) was that you could run multiple instances concurrently on the same server. With this additional functionality I would guess that one can now do the same at version 8 assuming that the repository location...

If you edit the attributes for that column, you can specify another replacement value for null values instead of the default spaces. If you were to define this column as nullable in DataStage it would keep the original NULLs from database.

I think it best to foreard this error to IBM through your support provider to see if they might have seen it before.

Normally if a 2-node job runs so will a 3-node one (this is not necessarily true for a 1-node job going to a 2-node job). It would seem that your problem lies in the DB2 side of things and thus the DataStage partitioning might not be relevant. You could see if switching to a 2-node configuration get...

Could your write job be converting a character field to your BigInt and that conversion is failing and writing nulls? Is the field nullable? Put a PEEK stage into the stream and see what values are going to the dataset. If you do a "view data" on the dataset in the job which writes to the ...

Upgrade from 7 to 8 is generally considered to be less reliable than doing a clean install. There are several threads on DSXchange on this subject already.

Does this IBM post address your issue?

http://www-01.ibm.com/support/docview.w ... wg21265788

How many processes are running for that job? I would try debugging it with $APT_PM_SHOW_PIDS set to true, identifying the process for DB2 and using the UNIX "truss -p {pid}" command to see what systems calls, if any, the process is using.
Also, see if your DB2 DBA can trace process status.

It can be done using stage variables, but I agree with Ray that unless there is a good reason not to use the pivot it should be used.

Add "$APT_PRINT_SCHEMAS" to your job and see if the schema going to your reject there is indeed an input field "ABC".

Please look into the Pivot Enterprise stage in the Parallel Job Developer Guide and, should your needs not be met by that stage, ask again here in this thread.

Ray, are you going to be the sensei for the class?

What happens when you enable rejects on the MQ stage? I would start with a simple job such as RowGen -> MQ to see if you have the connection set up correctly and that makes it simpler than adding Java and other stages into the mix.