DSXchange

Does "1:3" mean "1, 2 and 3" or (as suggested by your expected output) just "1 and 3"? In that case, how would you specify "1, 2 and 3"? It seems to me that you don't need DataStage BASIC at all - this could very simply be done with a DataStage job that simply...

Join (preceded by "don't sort, already sorted" Sort stage and relying on sorted data from the database only grabs one key value at a time from each link. Indeed, that's why it mandates sorted inputs; it would be horribly memory hungry otherwise, needing to load the entire right input into ...

mavrick21 wrote:I was about to ask - Can data in Hashed file be cleared without deleting DATA.30, OVER.30 and the VOC entry?

And I found out I can

DELETE FROM <HASHED FILE>

Posted here hoping this might be useful for others

is way more efficient.

Yes. Server jobs don't use the C++ compiler - only parallel jobs do, and even then it's only those with special stage types such as Transformer and Build stages.

Depends what you want to use it for. As a general rule I'd say it's meaningless everywhere (only a very few exceptions), since the clock is always running, even during startup, waiting for I/O to return, and so on. Also, row sizes vary, another factor mitigating against rows/sec being a particularly...

I doubt it very much. Do you even have the compiler run-times? If you do, export the executables with the jobs and don't re-compile.

Join is likely the better approach. Sparse lookup is slow, particularly when the database server is not on the same machine as the DataStage server.

mavrick21 wrote:I couldn't find the job which populated it.

Why not? Did you attempt a "where used" analysis" on the table definition for the hashed file?

The rows/sec figure is meaningless. Think about operation of a sort. It can't output any rows till all its input rows have arrived. However the clock starts running immediately the job starts. Therefore the actual rows/sec out of the Sort stage - indeed out of any blocking stage - will be substantia...

First question - are you really receiving timestamps (from a database) or are your receiving strings containing timestamps (from a text file)? Your answer to that question will affect the answer that we can give for your original question.

Your syntax for WriteSeq is incorrect - you have tried to use the syntax for Write. Check the DataStage BASIC manual. You can use as much code as you like, but only one call from the after-job subroutine area in job properties. That, however, can be a wrapper that invokes as many routines as you wish.

What's really missing is the End for the Then.

Immense changes. Consult the IBM web site (Information Center) to read the Planning, Installation and Configuration Guide.

Let's start again. How is the Null Field Value property set in your Sequential File stage? Is it set on the Format tab, for individual fields separately, both or neither? Is a zero length string to be regarded as null? Is a single space to be regarded as null? Whatever the case, you are going to nee...