DSXchange

You'd need permissions "all the way back up" to the root. What happens if you "cd" there and then attempt to execute it using "./orchadmin"?

If it was just gzipped, I would think so. The need to then extract a single file from the uncompressed tar archive is the extra wrinkle here.

And while you're searching, let us know what this 'other record' is exactly, how you will derive the key value for the Lookup.

So it sounds like you need to contact your official support provider for the patch. Have you applied that large "fixpack" of patches they have for your version?

If this is one of the "errors" thrown when you Reset an aborted job, these can all be ignored.

SHDISPATCH? Really... don't recall ever seeing that one, I guess I need to check again.

Talk to your AS/400 and UNIX administrators, see what approved ways you have to transfer files between those boxes.

I really don't see how this would be possible.

I've already said more than once what I think you should check / do, see my 3rd post for that. Don't really see a need to repeat it. Again.

The pipe is certainly a problem. Change it to a colon, which is the concatenation operator in DataStage:

Convert(char(13):char(10)," ", LNK_EXEC_TASK.DESCRIPTION)

I've had success redirecting sqlplus output to a temp file and grepping the file afterwards for ORA errors. If found they can be echo'd and the exit status set appropriately.

Don't guess, read the docs! Search the forums for a posted PX version of the Server EReplace function by DSGuru2B, that will do the substitution you need.

You'll need to get the whole domain/port thing working first, then you can hide the user/password bits in that file.

What database? Your script needs to farm any problems from whatever logs or session capturing you might be able to do. You can then echo those to std out and set an appropriate exit status so DataStage will notice.

So, in other words SFTP. Unfortunately, the answer is "no" until you get to the 8.x release so you'll need to script the transfer.