DSXchange

The uv command is safer to use than uvsh or dssh in this context, because it takes automatic care of removing defunct printer shared memory segments (and has the authority to do so (provided permissions and ownership on the executables have been set correctly), which uvsh and dssh do not). Don't for...

Ad nauseam, too.

Can you find it using a partial name search? In particular the "lib" part of the name may not be present. (Run this with superuser privilege so that permissions aren't a problem, or redirect stderr to /dev/null.)

Is the "k" date suffix meant to be part of the data or is it erroneous? You have to process it in either case.

Disable operator combination to learn the actual source of the error.

You have at least one stage in which DB2 partitioning algorithm is specified. Have you correctly specified the DB2 table from which DataStage is to seek the algorithm? This is a sub-property in the partitioning algorithm, which is set on the input link to the stage in question.

Let's call the job sequence JS and the job invoked by a job activity JA (which might itself be a job sequence - that doesn't matter). When JS is running, DSJobName is "JS". When JS is executing the job activity, DSJobName is "JS". Even when it executes DSRunJob(), the value retur...

The database_cs.txt files contain the database "native" name for a character map and the DataStage NLS name for the corresponding character map.

Request the same from your support provider or, if you know the map names, create it yourself.

CLEAR.FILE is NOT the same as a log purge. CLEAR.FILE destroys control records, forcing DataStage to re-create those next time the job runs. And CLEAR.FILE certainly does not provide partial purge (number of days old or number of job runs to keep). There is absolutely no command line interface suppl...

There's no value in posting the same question in multiple forums. It wastes your time and ours. Particularly since you don't appear to have bothered to search for your answer.

Don't.

Generate xyz.csv and use an after-job subroutine to change the name of the file.

It's FAR easier.

Yes, and a Search of DSXchange ought to find a suitable query.

Your routine does not return 0 so the job sequence assumes that it has failed.

You need to have an explicit trigger to handle the non-zero return value, so that this default behaviour of a job sequence is prevented from happening.

C'est impossible.

DSJobName does not get the job name until the job is actually running.

You would need to hard code it, or use a parameter value from the job sequence itself.

If all three are key, then your task is impossible for the given data. None of the C values match.

If only A and B are key, then it can be done.

Fewer bugs would be a good reason TO upgrade, in my opinion.