DSXchange

They're also given out when you attend any Ascential/IBM PX class.

The function you need is Convert() in a Transformer stage. See page B-9 of Parallel Job Developer's Guide

Now i am ready to meet any challange from client side with this forum as my right hand support. While appreciating your thoughts, that is not really the intended task of DSXchange. To help with the occasional uncertainty or difficulty, certainly. But to be your "right hand support", that kind of th...

The job is stopped. But it never got a chance to update its records in the RT_STATUSnnn table. Probably quickest is to Clear Status File from Director. Otherwise, you must reset the status value for job, resource and active stage records in RT_STATUSnnn, to explain which would take more time than I ...

You must make the changes on the DS server, particularly the uvodbc.config file in the project and the .odbc.ini file in the "home" directory.

No changes are required on the DS client machine.

DSNs only appear in the drop-down list in the ODBC stage if you've imported at least one table definition from the data source. When you're going through the process of Import > Table Definitions > ODBC Table Definitions in the Manager client, all DSNs named in the project's uvodbc.config file appea...

There is a (hidden) file called .odbc.ini in the DataStage Engine directory (the directory specified by $DSHOME). Sometimes an environment variable $ODBCINI has been created to refer to the location of .odbc.ini . The .odbc.ini file contains the definitions of all DSNs visible from the DataStage ser...

The job contains the name (strictly the "Catalog name") of the routine. When the job attempts to invoke the routine, DataStage searches in the Catalog for the location of that routine. An error is generated if nothing is found. If a routine of that name has been cataloged, and it has the correct num...

DSNs with associated database information need to be set up in .odbc.ini and a reference to each DSN must be set up in the uvodbc.config file in your project.

There has been a recent thread on just this topic; search should find it fairly easily. A good search term might be DBMSTYPE.

There's not a big difference for SELECT, but there can be a huge difference for INSERT and UPDATE.

Look for the function DSGetParamInfo() in on-line help.

Visual Studio .NET

That's cool

It's just an obvious thing to ask.

All repository design time objects are stored in dynamic hashed files with names beginning DS_, for example DS_JOBS, DS_ROUTINES and so on. All repository run time objects are stored in dynamic hashed files, and there is one set of these per job. Most have names beginning RT_, for example RT_CONFIGn...

Is the first Aggregator stage doing anything you couldn't do with a GROUP BY clause in the SELECT statement?