DSXchange

For what it's worth, these are in pairs. Checking the parent PID gets me this: $ tusc -p 4392 ( Attached to process 4392 ("sshd: dsuser@notty") [32-bit] ) [4392] select(13, 0x4001bc90, 0x4001bca0, NULL, NULL) ............................................................

Found out 'truss' is called 'tusc' on HP-UX. Here is the output from it: $ tusc -p 4392 ( Attached to process 4392 ("sshd: dsuser@notty") [32-bit] ) [4392] select(13, 0x4001bc90, 0x4001bca0, NULL, NULL) ..................................................................

Maybe a silly question, but I've been asked to help track down the crapload of sshd processes that can be found on the server that also houses our ETL server and I'm a little lost. We have 352 of these at the moment, going back at least month. Here's a snippet: dsuser 18394 18372 0 Jul 1 ? 0:00 sshd...

basu.ds wrote:please assume that is CSV file

Doesn't help. Your example seems to be normal file reading and the passing of column values to another process, not column names. BIG difference, hence the confusion.

This implements the same methodology as noted early on. Why 'from a transformer'? Will you be feeding in job names from a list or query? You won't be able to call it directly there, but as discussed you'd need a routine that would take a job name as a parameter and return (I assume) a comma delimite...

basu.ds wrote:ex:assume that i have a set of mail ids in a file i need to pick mailids from file and pass that value to routine as a paramer

How does that information match up with your example?

Ah... as you should have in the first place.

Please mark the thread as Resolved and it would be appreciated if you could post the actual resolution, what help they provided. It will help future searchers with the same question.

Not a lot of information to work on. I'd guess you don't have an index over the key fields and thus each update is a full table scan until found.

Confusing... you've said "column name", "column value" and "column name value" all in the same post. Which is it?

Check your syntax - you'll need to specify the extension on the "zip" file in the command you issue.

Typically means your XPath Expressions are incorrect. When they don't match the incoming data, nothing is parsed by the stage.

ps. The 'target file' isn't necessary, the XML Output stage is perfectly capable of doing its own output'n.

You might want to rethink that.

Heck, all you need to solve that problem is a big stick.

I use DSJ.ERRNONE but that choice doesn't affect the attachment, only subsequent use of the handle. Have you tried actually using the handle in subsequent steps? From the docs: JobHandle is the name of a variable to hold the return value which is subsequently used by any other function or routine wh...

Arg1 = Job Name
Arg2 = Error Level