DSXchange

No, you cannot effectively use the KeyMgtGetNextValue() routine in a PX job. Generate a unique sequence number in your job can be done by using the stage variables @INROWNUM and @PARTITIONNO (did I remember that correctly?). That is easy, now you need to figure out a way to make that number unique o...

Unfortunately not, the purging was designed before multiinstance jobs and wasn't modified to account for "sharing" the same log file. You could switch to time-based purging in order to keep recent multi-instance runs.

The two items, "multiple job instances" and "parameterizing values" are not related apart from both being part of DataStage. One is used to run the job mutliple times in parallel, the other is used to pass runtime values to a job.

Given that you are using PX and wish to have a unique sequence number across run youre best choice is to use an Oracle sequence. You can get the next sequence number by doing a lookup to an Oracle Enterprise stage which has user-written SQL, i.e. SELECT CAST(MySequence.nextval AS decimal(9&#...

If you replace your RDBMS output stage with a sequential file or a dataset, does the error persist?

What error does your job abort with? Nulls can usually be handled.

In the transform stage just check for @INROWNUM greater than 1 and the columns eq to your header value of "|Number|Name|Country|" and just don't pass that through to the output.

4friends - that is the 3rd question in a row that is answered directly, clearly and in detail in the documentation. That is the 3rd strike for me. Perhaps someone else might wish to replace the docs for you.

If you think about it, turning off combination just means that more processes are doing the work. If your job (with combination) uses a lot of CPU then you might have been bottlenecked there and by disabling combination the load is spread across more processes and if you have enough physical CPUs on...

Mhasan - I didn't give you the complete answer on purpose. The DateFromDaysSince() function using -1 will give you date one day prior to the input. So all you need to do is change your date to the first day of the next month (perhaps using string-based functions?) and then apply DateFromDaysSince()....

Try setting APT_DISABLE_COMBINATION to true and see if you do get a stage name or at least a different error message.

Oddly enough I have a call open to support for a simliar issue - but in my case the settings for time-based and row-based commits are being ignored but the commit isn't done until the job finishes. What platform are you running on?

Try

The same system variable exists in Parallel. But each node has it's own @INROWNUM, so in order to get a unique number you will have to use the variable for the partition number as well (I'm not at a DS client now so cannot check what that variable name is, but you can find it in the drop-down menu)

That means you are doing some function call in your transform stage using a null string where the function doesn't allow null values. Look at your stage variables and derivations and see which ones manipulate strings.