DSXchange

Call stored procedure from any passive stage that supports them, for example ODBC stage. Search the forum for more information; it's been covered before.

Yes, by using the "BASIC Transformer stage" (this is not the same as the parallel Transformer stage). Note that you will almost certainly experience some degradation in throughput.

Your 32-bit hashed file has become corrupted trying to extend beyond 2GB. The links Michael provided will give more information. You need 64-bit hashed file or distributed file to exceed 2GB. Or maybe you can store fewer rows or columns in the hashed file.

Aren't there already SDK functions to deal with 1970-based dates?

The best (safe) utilities to use are:

format.conv -export (then format.conv -import) if the hashed files are SQL tables

uvbackup (then uvrestore) only if the hashed files aren't SQL tables

Observation: when things stop working, the statement "nothing has changed" is false.

There IS a C-callable API. In fact, dsjob began life as simply an example of how to write code in that API. The API is documented in each of the Server Job Developer's Guide and Parallel Job Developer's Guide.

Main considerations, it seems to me, are

whether other, non-DataStage, updates may be made to the table (in which case use the database rather that DataStage)

whether the bulk loader (if you're using one) can make use of database-generated keys - if not, you need to generate them in DataStage

If the $DSHOME/bin directory is in your PATH you can execute the dsjob command from anywhere. Or you can use the full pathname of dsjob, as illustrated below. But you do need the environment variables which are set in the dsenv script to have been set. . $DSHOME/dsenv $DSHOME/bin/dsjob -run -jobstat...

I'll assert that you can't open that particular job from any client. The RT_CONFIG118 (hashed) file contains run-time configuration information about job number 118. It is written to by compiling the job. For some reason DataStage is unable to open that particular hashed file. It may be permissions,...

Read two documents, both of which you have with the software. One is the README. The other is the Installation and Upgrade Guide which you may have to search for on the clients CD, but it's not in any compressed file. Between them these contain absolutely everything you need to know, including the U...

It's probably not necessary to reindex all tables, but it's quicker than wading through the repository database for the project trying to figure out which of them needs reindexing. If you'd told us which branch of the repository you had selected, and from which DataStage client, the answer probably ...

VMARK began in 1984, so this is the earliest possible date for UniVerse. UniVerse was written to mimic Prime INFORMATION, but to run on UNIX (whereas Prime INFORMATION ran only on the proprietary operating system PRIMOS). Prime INFORMATION resulted from work done by DEVCOM in the 1970's to provided ...

Have you imported the Stored Procedure definition? This is an essential first step when working with Stored Procedures from DataStage; the "table definition" is used to ensure that the number of columns in your design matches the number of columns consumed/returned by the Stored Procedure.

While there is no documented limit on the number of versions, there may be physical factors that intervene. At one of my client's sites they ran into the "too many subdirectories in directory" limit on Solaris. This was caused by the huge number of dynamic hashed files in the Version project. The cl...