DSXchange

There are various ways to achieve this. No tool can do this without knowing the "rules" and you haven't specified how you wish to do this. Are the rules based on some table? If they are based on successful completion of previous runs, then I recommend you read the documentation on DataStage restarta...

Do you have any jobs that can read from or write to DB2 that are working? If yes, do you have any jobs that can read from or write to this particular table with this particulare userid that are working?

What state was X3 in when the batch started - most likely it failed a previous run. When you use job activities you can specify "reset if required, then run" to avoid this issue.

Is this a remote drive?

No workaround since the issue's cause hasn't been identified. What about the answers to the second question - is this a new problem or did it work before? Does it affect just this job/table/database?

Are "Source" and "Target" absolute paths? Try adding a "cd {path}" command to your batch which changes to the directory from which you successfully manually called the .bat file.

Can you do a "DB2 connect" from a command line to this instance? Is this a new error or a new installation?

The simplest way is to add a parameter to M1 such as "SkipS1" and use that to skip executing the Job Activity in the M1 sequence.

What is the error with which it fails? My initial guess is that you are using relative paths and since the default working directory of the shell is the project directory this is why your batch is failing.

I'm not quite sure what the direction of the question is. You can start any DataStage job from any sequence use the Job Activity Stage, and you can also start any DataStage job from another job using either the builtin BASIC functions (DSAttachJob(),DSRunJob(), etc.) or through executing a shell "ds...

Helle veera24 and welcome to DSXChange.

You can specify a reject link to database writes in the database stages, this link can go to program logic or output files in your job that can attempt to clean up the errors. Once the data has been corrected it can be re-run to be written to the database.

The performance benefits that I've seen with lookup filesets isn't very significant, but lookup filesets have the drawback of not letting you view the data using any tool and need to have the keys that are going to be used hardcoded. I have used Datasets for development in the past and then, once al...

The only supported and correct way to migrate DataStage code is through the use of the export & import functionality; doing anything from the UNIX level will usually result in corrupted projects.

Was any of this "Data" in the DataStage project directory and did you do a UNIX level copy & deletion?

I use the row generator in jobs all the time. I think it is put in this category because it doesn't logically fit anywhere else.