DSXchange

If WAS stops after you attempt to re-start it, check SystemOut.log and also check that the XMETA owner user password has not expired (and that the repository database is up).

Remove the entries for a particular invocation from the RT_STATUSnnn table. This will allow the entries for that instance to be removed from the RT_LOGnnn table, which should occur automatically.

OK, use Nested Condition activity to search the query (use Index() function) and select the appropriate job to be run.

Yes, these are in a sequence.

Convert all English characters, including punctuation, into "" then see if there's any characters remaining.

The checkpoints themselves are stored. The routine result is not.
If the routine fails, it does not get a checkpoint.
From memory (and I have no way of checking) they are stored as a multi-valued list in the job record in the RT_STATUSxxx table for the job.

When you installed the first time, did the question about MQ (and the choice between client mode and server mode) appear? If so, how did you answer it?

The routine return value is not stored.

It does, however, trigger a Failure if its value is not zero.

You need to handle non-zero values explicitly (and, for preference, include an explicit Failure trigger).

Further, there are records with different formats. You can nominate the first ten fields as F1, F2, ..., F10. Beyond that you need to have a bit more knowledge if the structure. You can view entire records using the LIST.ITEM command, but this shows only the data in populated fields - you don't get ...

... unless you specify "multiple row return" in the Lookup stage.

The "upgrade in place" won't be available until about March 2013.

Decimal values are stored in binary. Convert to VarChar if you want to see their text equivalent. You're lucky that the binary representation did not corrupt your stty settings. The data browser effects a conversion.

"before few days", eh? Has the password expired?

HOW (on what columns) is the partitioning done? What partitioning are you using for the Lookup stage? Have you ensured that inputs to Join and Merge are correctly sorted?

What exact version are you running? Is this a server job (as marked) or a parallel job (as posted)? No point our trying to guess this information, which will affect the answer we give.

So, one server job to execute the query and store the result in its user status area, a Nested Condition activity to filter based on the value in the user status area with ten triggers to fire the ten Job activities. Maybe an Otherwise trigger as well.