DSXchange

Craig caught that:

Since TrimLeadingTrailing() cannot be used on a NULL value, the code should read:
I assume that this derivation does not show up in red in transform stage designer?

The UniVerse manuals are different from DataStage BASIC, the correct manual to use is installed as a PDF along with the client software. But in this case it looks like it is a Parallel Extender question and the routines/functions written for PX are c++ calls and are bound to an executable in a very ...

This can be done in a transform using 4 stage variables:

GroupCounter = IF Key1=LastKey1 AND Key2 = LastKey2 AND Key3 = LastKey3 THEN GroupCounter+1 ELSE 1
LastKey1 = Key1
LastKey2 = Key2
LastKey3 = Key3

I am not sure of what sort of a prefix the CFF would add. Try outputing ASCII or with a EBCDIC file on UNIX using "dd conv=ascii if={filename}|more and telling us exactly what the prefix consists of.

Ask your DB2 administrator what character set the database is defined in. Make sure that setting is identical to what you specify in DataStage for the DB2 stage; that is probably the cause of your error.

What character set is the DB2 database stored in, and what NLS settings are you using in your job?

I haven't tried an upgrade from 8.01. to 8.1, just fresh installations, so I don't know what else to suggest apart from contacting your support provider.

Do you have custom SQL DML in the Oracle stage? It is highly likely that the problem lies in the data or table definitions (keys, constraints, triggers, etc.) and not in DataStage directly.

Addendum - this time Craig was faster on the trigger

If the job runs with more than one node, each of them would process the same constraint in parallel, i.e. with a 4-node configuration you would get 4xp_RowCountLimit rows.

The NLS_LANG environment setting is for Oracle, not DataStage. You need to go into the DataStage administrator and perform your changes there.

The list of projects that DataStage displays to you is held in a hashed file called UV.ACCOUNTS and it seems that your project has been successfully removed from there. Perhaps the user doing the deleting didn't have sufficient rights to remove all of the files and the directory. Try renaming the di...

Start it off simply and declare just one user, then ensure that this user has access rights to DataStage; do this by logging in as the user then attaching to the DataStage directory as specified above, executing the dsenv scription and then trying bin/dssh and if you get the ">" prompt lea...

What is the data type in the source dataset?

$DSHOME is an environment variable that isn't necessarily set. There will be a file called ".dshome" in the root directory, so doing a cd `cat /.dshome` will get you to the right directory, then doing a . ./dsenv will set up the environment and then you'll have $DSHOME set correctly. What ...