DSXchange

Do you have Enterprise Edition? If so, import using the Orchestrate orchdbutil utility. There are known issues with OCI, and ODBC must make certain assumptions because of its own protocols.

Don't you need a quit in DB2Cmd ?

A sparse lookup is where you do a lookup against the DB2 table.

You are not doing this. You are loading a result set from executing that query into a virtual Data Set, and performing the lookups against that. This is called a normal lookup.

Is DSLink147.xxx defined as Nullable ?

Welcome aboard. :D

Clearly you have NOT "ran a job through sequencer".

Try compiling the job and running it in isolation. Then try running it from the job sequence (note: not "sequencer"). Tell us what appears in the job sequence's log.

Unless you are performing a sparse lookup you will always be using two virtual Data Sets for two lookups via a Lookup stage. You can see this happening in the score; each is built using a LUTCreate operator. So, if the queries are different, your second approach is probably to be preferred, as it wo...

Wait for "that was only an example, we actually have one column but multiple rows".

You write your own encryption/decryption code and put it on the Code tab of the Build stage.

It can be done, and will be handled automatically because the current version is so old. Version 5.2 runs on UniVerse, and has an "itag" of 0xace. DataStage 6.0 and later run on DataStage Engine and has an "itag" of 0xade. Version 5.2's RPC daemon listens on port #31438, while version 6.0 and later ...

My line of thought is that CoSort sends "end of data" as soon as it's available (for speed) rather than waiting till the "cleanup" phase is done. After all, they are competing in a marketplace where fastest to return sorted result set wins. And if ALL you're doing is sorting, it's a good strategy.

... or preload a Lookup File Set with the results of the same query. I repeat it here in case Josh edits his post to add a WHERE clause!

I hope you're documenting these nuances (and keeping the generated Job Control code) for when you report the "bug" to IBM.

Please post your question in a new thread. It is NOT the same, and only vaguely similar, to the question asked - and already resolved - on this thread. There is an answer, but I'll not post it here.

Loosely, encode = zip (compress), decode = unzip (uncompress).

The Decode stage probably could be used with a command line decryption tool, but decryption is not built in to the stage - I needed to make that clear.

It can be retrieved, but you have to figure out (= hack) which particular fields store the user-defined INSERT and UPDATE statements in the DS_JOBOBJECTS record. Then you could use the EVAL "@RECORD<field#>" technique that has shown up occasionally here.