DSXchange

Lando, the coding you can do directly in a transformer are limited to single-line constructs; so a classical CASE statement isn't possible. You can write your own "IF THEN ELSE IF THEN ELSE ..." statement but it won't be particularly legible. You could always write your own subroutine with 2 argumen...

This is not stored as a file, but as a record in the VOC hashed file. It is not visible or accessible from UNIX.

Kumar,

you can enter the command "LIST DICT {tablename}" from TCL to get the UniVerse style DDL of most of those hashed files.

Magesh, you are trying to fix a problem without knowing what your problem is by applying a fix to some other issue. With the suggestions you got in this thread you will be able to identify the cause and you can then choose how to solve it. At the moment it might be a memory leak issue with your rout...

Rajesh, this information is stored in the DataStage repository hashed files. It is accessible via many different methods including: 1. The Director client program 2. The UNIX/Windows command line using different command line options of the dsjob program. 3. The BASIC programming interface; see the B...

Your question is far too broad to answer. It is like saying "I want to know how to make my car go faster". Here are a couple of evergreen tuning suggestions: Disk I/O is slower than memory - so try to avoid reading and writing your data to or from disk whenever possible. Try to pre-load your hashed ...

Magesh,

what kind of a test is that? The original error didn't show up until row 16,316,653 according to your post.

Check up the documentation for DSGetStageInfo(); I'm not at a DataStage PC right now so I can't check up, but one of the values you can retrieve there is for the Stage Variables. I don't think that the derivation is returned, though.

There are many ways to collect that information from inside jobs and also from outside of them. If you want to collect stage variable value information the easiest way is to use DataStage and pass those values down a link and write it straight to a sequential file in the job.

Did the job have the same error using a 1=2 constraint or writing to /dev/null? If the error went away, then the source of the problem has to do with the sequential file. If the error remains, then take out your routine call and see if the error goes away.

Magesh, put a constraint "1=2" into your transform and retest. This will evaluate to false for each record and ensure that nothing gets written to the sequential file. Alternatively write to a sequential file called "/dev/null". Does the error still happen? If yes, take a look at your transform deri...

That means that at least the cause of the error is explained - the files are being created somewhere in your environment as normal sequential files instead of as pipes. What kind of collection algorithm are you using? If you change the name of the stage does the error re-occur (if not, then it is so...

Do a "reset" from the director and look at the entry with the heading "from previous run" to get more detailed error information; it is not possible to diagnose an exact cause from the information you have provided. When you say that your sequential output file is over 2Gb does that mean quite a bit...

The error is in an ipcopen() call so the files would need to be pipes. Could you delete the temporarry files in question before trying a new run? It might be that the error comes because DS is trying to do ipc calls on an incorrect file type.

The site that I am at has not seen the problem in the version control project(s), only in certain development projects. But the limitation is present and diagnosing the error when it occurs still takes up time. Converting all RT_STATUS<n>, RT_CONFIG<n> files to static will do the trick.