DSXchange

1. It's smart enough to share only one copy.
2. I'm not aware of any locking/blocking strategy. But, then again, I haven't tried it. I know it's not possible in the same job, but that's managed (prevented) by a pre-compilation sanity check.

What are the data types of your stage variables?

Making the file a delimited format will solve your padding problem, however it may not be acceptable to the consumer of the file. Delimited is usually the appropriate choice when variable-length data have to be stored in a text file.

Is there a way to export the log files out of datastage to create a seperate local log file (txt format) ? You can create a DataStage server job to achieve this. The only tricky part is determining the log hashed file name; you can do this using another server job (SELECT JOBNO FROM DS_JOBS WHERE N...

In the Lookup stage you can return the lookup key. You can not assign (derive) values in output columns. Downstream, in a Modify or Transformer stage, test whether that returned key is null; if so, your lookup failed, otherwise your lookup succeeded. Of course, if your Lookup stage has a rejects lin...

Do you get any error message?

I suspect that the client machine is running out of memory. Monitor memory usage (Task Manager, always on top) when attempting a large View Data.

2055/00/00 is not a date. Maybe that's the issue. Try 2055/01/01.

The only things that prevent writing to sequential file are constraints, permissions and "file system full" conditions.

Not necessarily. The layout of the error message suggests that the key value used contains two "mark characters". By default, hashed file keys are not permitted to have mark characters (dynamic array delimiter characters) in them, with the exception of the "separator character" for hashed files with...

If it's not that, then maybe either your system is overloaded (the subroutine did not complete within its allotted time) or the Repository indexing may need to be rebuilt.

Is there a "following" database message in the log?
Have you made sure that the executing user has at least r-x permission to every directory in the path?

Did you simply want to combine them, or do you also want to verify that the number of detail records is as recorded in the header?

The Aggregator stage performs standard deviation as one of the aggregate functions.

Make sure there are no nulls in the column being processed.

Why do you assert that the performance issue (whatever is meant by "performance") is with the extraction phase? Have you proven this?

What stage type are you using for extraction?