DSXchange

Define 'archive'. What do you want to happen to the old file(s)? Or not, just noticed this is suddenly 'Resolved'.

Is your delimiter, when you 'cat d3.txt', in fact a comma?

I would think that, in a PX job, a Row Generator would be the most appropriate starting point. With no equivalent in Server to that stage, we use a Transformer. However, you could use either I would imagine. [shrug]

I usually seem to see that when someone kills the pid in question.

What's your 'WORKAROUND'?

Yes, it is much happier with a comma delimited list. An "ls -m" will generate it for you automagically.

Don't do it 'after job', consider doing it outside your job. For example, a job that gathers this for all jobs or a series of jobs rather than having to put this call in every job.

Aieeee!

What did you put in the Start Loop's Delimited Values box? That's where your command output goes. The job should use StartLoopName.$Counter for the filename so it gets one 'off the stack' each iteration.

First thing would be to verify that your character actually exists in the target character set. If your source and your target use the same character set, you can just load from one straight to the other, otherwise a conversion needs to happen. When the source character set (controlled by the job se...

You'd need to switch to getting full log details rather than a 'summary'. That means DSGetLogEntry and a lot more work on your part.

If that was an apostrophe (hex 27) it would have loaded fine. I've had the same issue in the past when the source is something like Word and you get them dang 'smart quotes' rather than a simple apostrophe.

What is your NLS_LANG setting for your database?

Sounds like the parent data should go into a hashed file and then the other 2 stream in and you do a lookup based on matching keys. Output the 'merged' data to a sequential file.

VCInDSX wrote:If i can execute the procedure without any additional stages, that would be best

You can't in a job. Something must drive it.

Sounds like you need to get back in touch with IBM.

Depends on the external format your timestamp is in. If it is ISO like - "YYYY-MM-DD HH24:MI:SS" - then you can compare those strings directly.