DSXchange

Please re-read my earlier post. It contains two solutions.

{ node "node1" { fastname "abcd123" pools "" resource disk "/inputdir/DataSets/DataSets_N1" {pools ""} resource scratchdisk "/inputdir/Scratch/Scratch_N1" {pools ""} } node "node2" { fastname "abcd123" pools &...

@UserStatus is not available in other processes.

Look at the job log for job 2 to see what it actually received. Did you pick the activity variable from the expression editor when filling in the parameter value expression in the Job activity Job2_Activity?

lib64 if you have a 64-bit version of DataStage (e.g. on AIX 6.1) or lib32 if you have a 32-bit version of DataStage. DataStage is just another client application as far as DB2 is concerned. We are using DataStage 8.1 to connect to DB2 versions 7.1.1, 9.5 and 9.7. Based on that combination, I would ...

1. Job1_Activity.$UserStatus - pick it from the list of operands in an expression.

2. Job1_Activity.$UserStatus - pick it from the list of operands in the expression editor.

Import table definitions. Load the imported table definitions into job designs. Never create table definitions in job designs where the table already exists.

It's all in the manuals. And probably searchable at DSXchange. Radically different between versions 7 and 8.

No, just use a DIR /B command. The output of that command can be used as your "list of things" for a Start Loop activity, or may be interrogated using the Index() function in a User Variables activity to get the Boolean values that determine whether jobs will run or not.

Sort by date and capture the last row (sort and tail commands).
Sort by date in descending order and capture the first row (sort and head commands).
Because this is a parallel job, you do have MKS Toolkit installed and can therefore use UNIX commands such as sort, tail and head.

Because routine1 is not upstream of routineE1, there is no mechanism apart from storage on disk (doesn't have to be a hashed file) for routineE1 to access activity variables of routine1. In short, "no".

No real performance difference over an equivalently configured cluster of machines. However, the grid management software means that you can get more processors if they are free of other tasks, and can also manage events such as losing one of the machines completely - it simply does not schedule tas...

It has always been the case that you can request IBM for an evaluation version, but you have to convince them that there's a good likelihood of a sale (check the prices before committing!) and it will have a very limited lifespan on its license.

Harini wrote:But i would want all the jobs as a single dsx file. Is it possible to do that?

It is not possible. You could construct a single DSX file out of the individual job DSX files, which would involve removing the individual files' headers and creating a header for the combined file.

You should only ever work with imported table definitions.

Of course it's possible. But it's typically not a separate role. Typically it falls within the purview of an Information Server administrator (though it can be separate, particularly on larger installations).