DSXchange

Read the error message carefully, then read the Install and Upgrade Guide and complete any steps you missed (such as permitting processes on one machine to execute on another as "trusted"). You really should test configuration files before attempting to use them. There is a test utility on the Confi...

I think it's a parallel job. For example you don't get references such as [&DSCAPIOP ...] in server jobs. Though I admit to being a bit mystified by array size and transaction size, with no real parallel DB2 stage experience I can't claim for certain that they don't exist as properties in that s...

Can you please post the generated OSH?

Force compile DOES ensure updated stage properties, unless some kind of corruption or permissions problem exists in your Repository.

Please check the following.

FTP stage

ORABULK stage

The answer is no. A Lookup File Set performs an almost identical function to a hashed file feeding a reference input link. The internal mechanism is invisible. If it makes you feel comfortable to believe that a Lookup File Set could locate its keys using a hashing algorithm, then you're home free. (...

@INROWNUM is a system variable that records the number of rows received on the stream input link. Since there is only one stream input link it is simply impossible that @INROWNUM can contain duplicate values. Of course a design can use that value more than once, for example direct it onto more than ...

Welcome aboard! :D

At the top of your screen is a link to the forum's Search facility. This question has been answered before. Try searching for an answer.

If you're really stuck, post back here.

Is someone faffing around in your repository removing SQL statements from job designs?

Have your DBA trace DataStage-initiated sessions to detect what actual SQL is being received.

Is this a parallel job (as you indicated) or a server job (as indicated by the forum in which you posted? The answer would be different in each case.

OK, it was the WHERE 1=2 that got to me!

You don't need telnet, but you do need TCP/IP, and the ability for processes to communicate via sockets. You should use as fast a network connectivity as you can get - not less than 1 Gbit imho. You didn't actually need the full DataStage PX installed on each, unless you want to run separate server ...

WHY do you want to run a DELETE statement that will never delete any rows?!!

Just bypass processing if it's the current job. The status of the current job is always "Running".

It's not complaining about vmdsapi.so, it's complaining about libvmdsapi.so (on some systems this is simply a symbolic link to vmdsapi.so but, even so, it must exist).

We'll have to agree to disagree there. I took the opportunity to highlight more efficient versus less efficient practices. People are always banging on about performance - this is one area that is often neglected.