DSXchange

You never remove them. DataStage needs them for its effective functioning. Do you mean "purge log files" or "clear status files"? In either case, why do you want to do this?

Have you written a parallel version of the Iconv() or Oconv() function that you can share with us?

If you have, an "MCA" conversion will return just the letters - no need for Ereplace().

Not all conversions are automatic as in server jobs. Your mindset is still on server jobs - you even marked this as a server job. The error message codes indicate that it isn't. You need expli ... No, I am not designing this Job in server its a PX job. I tried with the above results still while com...

The syntax (argument order) in your Convert() function is incorrect, and this approach is not general - as Craig notes, it removes only upper case letters. Trim() achieves nothing here. Convert("ABCDEFGHIJKLMONPQRSTUVWXYZ", "", Upcase(InLink.TheString)) is more ge...

Best is that you saved the Data Set's table definition from the job that creates it, and loaded that table definition into any subsequent job that uses the Data Set as source. Then the answer is a simple Usage Analysis from the Manager client (or from Designer client if you're on version 8.0). No in...

The easiest approach is to use a pair of stage variables to detect change in, and remember the previous row's value in, a particular field. If you want to use routines in parallel Transformer stage, you must create the said routines - none ships with DataStage - or maybe get a consultant in to creat...

Specifying the Null Field Value property is sufficient. DataStage will translate this value to NULL on import, and therefore - unless your job design interferes with it further - send that NULL to Teradata.

Craig remembers correctly. Importing a table definition establishes the DSN in a file called uvodbc.config in the project directory on the DataStage server machine. The DSN drop down list is populated from this file. If you don't want to import the table definitions - in which case you are not follo...

You could create your own parallel routine. Make sure it handles letters of both lower case and upper case if this is what your business rules require.

For small volumes you could use a BASIC Transformer stage and use the DIGITS and LETTERS Transforms.

If you send nulls from DataStage to Teradata, Teradata will handle however it has been configured to record them in storage (whether presence bits or any other mechanism). There is no need to fiddle about with bits within DataStage - just send the NULL values.

As Ken said, there are no data types, and therefore no differences based upon data type. The size of the hashed file is theoretically irrelevant, because the hashing algorithm means that there should be exactly one logical I/O generated for a lookup. No index, no table scan. In practice, of course, ...

Re-open the help for the Administrator client (dsadmin.chm).
Search for the topic "Project Properties Window - General Page".

There you will see the check box and also a link to the "Configure DataStage to send process meta data to MetaStage" topic.

Good. We will wait for you to post them.

You almost certainly need a Custom trigger on your Routine activity. Without one, DataStage will assume that a return value of 0 means success and any other value indicates failure (the same as the exit status of operating system commands).

Perhaps the parallel streams into SQL Server are conflicting with each other. Try running the job with a one-node configuration file, to test this theory.