DSXchange

If this only happens to you on your PC then I would think the client should be uninstalled / reinstalled.

Never said anything about using Auto partitioning. Was wondering if you're concerned about which partitioning method the Data Set will use, why not set it to Hash in the Data Set stage itself? Maybe I'm misunderstanding what your "How do I make sure the hash partition on those keys which I have...

Why not set the partitioning directly in the Data Set?

Hmmm... I'd try changing the FD to show PIC S9.9 for that column and see if that works.

You need to switch to DEBUG, this should be helpful: https://www-304.ibm.com/support/docview ... wg21509567

If you need to manipulate the value and then send it in as a job parameter then you'll need two jobs and a Sequence. And he specifically noted a Server job for the first step so you can leverage USERSTATUS which makes the transfer of data between the jobs trivial.

suryadev wrote:Please suggest how to store that value and pass it in the query for the Table2 in parallel job

He did.

It's not strange, it's the nature of sequential media which supports multiple readers but only a single writer. You'd need to sequence your jobs so they append their output.

Simultaneously? No.

Your script would have to count the number of times the job had been launched and stop at 5. You could also monitor the number running and when it drops below 5, launch more until it is back at 5. Repeat until you run out of table names.

If that was true, you wouldn't be seeing the warning.

The keys you are using in the Remove Duplicates stage do not match with the keys you sorted on before it.

Probably. I'd check the release notes for your version or ping support. It could also be something that changed in the Oracle client version, if that was upgraded between the DataStage versions. Ray is correct though, neither of those string sizes make sense for "working perfectly", it nee...

You were taking advantage of a bug in the earlier version, something they fixed in a later release. Not exactly an uncommon occurrence.