DSXchange

Who let them depart without securely handing over the passwords? There is no way you can find the passwords "on the server files" - even if you could, they'd be stored in an encrypted form. I agree, demand the passwords from the previous vendors, perhaps with the threat of litigation if ne...

Don't believe so. We use ISUSER for all identification fields (such as created_by, updated_by).

If your transaction count is 2000 then DataStage will send a COMMIT request after each 2000 rows sent to the database server.

Every transaction writes to the log, of course.

As to why commits aren't occurring, you will have to work with your DBA to determine that (if it's true).

DataStage has lost track of one of the temporary files created by a tsort operator and has discovered that that is so when trying to clean up.

You should regularly delete these orphans from the scratchdisk.

USER is the standard UNIX environment variable. It's the user ID of the user who is logged in - the identity under which the job run request was made.

First let me stress that this table is something your site has created, it's not part of DataStage out of the box. I would imagine that MasterProcess Identifier has its value generated within a master controlling sequence which then passes it to all other jobs, including the one that updates your co...

Are you using a Surrogate Key Generator stage or a Transformer stage or a Slowly Changing Dimension stage to generate surrogate key values?

You get to create routines on the Advanced DataStage training class from IBM (now offered through its training providers).

Here is probably as good as any. A search for "parallel routine" will throw up a few, but you'll have to filter for those that actually contain code.

You might try a search for "pxReplace" but that code's perhaps a little too detailed for a beginner.

1. The error message is generated by DB2, not DataStage. 2. The error message specifically states that the (DB2) database manager is not able to accept new requests, or has terminated the specified request because of an error or a forced interrupt. Unless you submitted a Stop Job request there's no ...

MKS Toolkit is still provided, but DataStage itself no longer uses it. Instead, all code in DataStage engine that used to call UNIX functions now calls equivalent native Windows functions, when on a Windows platform.

There is no refresh of normal lookups while the job is still running.

You would need to stop and restart the "always on" job to pick up any changes.

That error message suggests to me that the problem IS on their side - possibly that the database is quiesced, or that the maximum number of simultaneous connections allowed has been reached before your DataStage job attempts its connection.

Or, looking at it from the other side, what do you get if you include the rule constraints in the SQL query? select count(*) from CUST_TYPE C, inner join CUST_ALL A on c.cust_key = a.cust_key, inner join IW W on a.iw_key = w.iw_key where c.Cust_Type_Ind is not null and c.Cust_Type_Ind IN ('I', 'N')

Contrast what it does with what it reports. "Returned from job" is not the same as "extracted from source". If you save the scripts you may be able to view the job logs, and if you enable logging of row counts you will get more information about how many rows were extracted from ...