DSXchange

But, presumably, combine the contents of row N from file 1 with row N from file 2 to form row N in the output file.

Otherwise your answer is simply cat file2 >> file1

COBOL is not "smart enough" to do that automatically. You have to define your column definitions as fixed width (and accurately!) in the file definition. DataStage BASIC (we're comparing programming languages now, not ETL tools) can also quite happily deal with variable length unterminated records, ...

"" is not a valid value for a date data type. Therefore you can not write "" into a date. What you might be able to do is to represent NULL as "" (Null Field Value property) provided you make the output field nullable, and feed it nulls where you want "".

Do you want eight columns per row in the target, or three? This is not clear from the original statement of requirement, but will certainly affect your choice of stage types in your design.

Job sequences have "automatically restart from point of failure" as a compilation option in the job properties dialog. Anything else, such as handling a partially-committed load, you have to design in.

Be more precise what you mean by version control. In DataStage, Version Control has nothing whatsoever to do with job type, so your "in DSPX" is either misleading or moot.

Enrol in some training; it's a fairly common requirement. Or search the forum, as suggested.

If you want one-on-one training, you need to engage someone professionally.

Yes you can. Give each instance of the job a unique invocation ID. Start them all from a job sequence, with no dependencies. That's as close to exactly parallel as you can get without using a scheduler of some kind. Beware that ten instances of a parallel job is quite likely to swamp your server wit...

OK, I needed to establish that. It is sound advice, but you didn't mention DB2/390 in your original post. You do need the API stage. Have you set it to execute in Sequential mode? Multi-instance running is enabled via a check box in the job properties dialog. But you will need to have WHERE clauses ...

Welcome aboard. :D

Ask yourself how you would do it if they were SQL tables. Probably the easiest way is to add an artificial key (line number) to each using something like sed, then use this as the join key.

Either make sure there are no delimiters or spaces in that job parameter, or use a different job parameter that has the same timestamp but without delimiters in the file name.

Search the forum, this has been discussed a few times already. There are at least four techniques. Easiest is to do it before you start this job, and pass the start value as a job parameter that you can use in the Column Generator (or Surrogate Key Generator) stage.

Did you misspell "scratch" as "scretch" in one node definition within your configuration file?

Is there some reason you're not using the DB2 Enterprise stage, the one with inbuilt parallelism?

#SchemaName#.TableName

Never make the table name a job parameter. Following this advice means that things like lineage analysis and usage analysis will work properly.