DSXchange

Exactly, which is why one would need to play the game of writing the data out with multiple keys (so as to retain the duplicates) and then reading it back with fewer keys for the "multi-row" part. More complicated than that of course, as a search would reveal, but that's the gist of it.

IBM should be happy to provide those details to you while they've got your arm behind your back. There are quite a number of improvements in the product from 7.5 to 8.1 but (as noted) it does come at a price. I'd wager that Vincent has blogged on the subject over at ITToolbox. More than once.

And if you keep reading the link you provided, you'd see that support was withdrawn for DataStage TX 8.0 and replaced with the equivalent WebSphere TX 8.1, 8.2 product. Nothing to see here, move along.

Not sure what the confusion is, all that post is saying is to concatenate the chunks back together in the order you created them. Use the operating system command 'cat' to do that.

So, UNC path - this file is actually on a remote server. UNIX or Windows? Is the filename a job parameter or coded in the job? No clue what a 13 is but I'd double-check permissions.

Windows is not case sEnsiTive. Can you post the full unedited error messages, please, from the scheduled run?

That's just it, there are no duplicates in a hashed file unless you fake it by follow the technique suggested that the search would turn up. Let me make sure we're both on the same page - if you want one input row to hit a reference lookup and return more than one lookup result (your 'duplicates'), ...

Sounds like what you want is a "multi row result set" which requires a UV or ODBC stage to implement. Search here for all of the gory details on how to set that up.

Primarily 'random'.

Either not compiled or already running, usually. I personally think running anothe job 'after job' is not a very good idea, but that's just me.

Sorry, my helicopter is in the shop.

Check this thread: viewtopic.php?t=115051

Of which 'local files' do you speak?

For 7.x and earlier you can usually (i.e. the default location) go to $DSHOME and then ".." back up a level to find the "Projects" directory. However, that being said - if you don't even know where it lives, I'm wondering why you "need" to know that. I'd be very very ca...

First person you should take this to, IMHO, is your DBA. That or Google for examples of the proper syntax.

Obviously, though, something is different about it. The bitch is going to be finding it. Don't recall if this has already been asked, but can you run the equivalent sqlldr session from the command line on that box with that user? It won't truly be equivalent as the stage uses pipes as the input sour...