DSXchange

Run the job on a single node, see if that 'solves' your problem.

I meant you 'stash' it on encountering the PROV_TB record as that's when you know what it needs to be on the following records. So basically a stage variable that is set when you read that row and left unchanged for the others. Something along the lines of: svCurrID: if TABLENAME = 'PROV_TB' then CL...

Please post some actual (not made up) examples of your CLOB data so we can see the strings you have to work with.

Once more into the breach...

Understood and no, it's not really different... just a variation on a theme. And my post explains how to do it. Stash it on the PROV_TB record, use it on all of the others.

Have you tried it, have any specific questions?

It's not that different from the other conversations we've had on stage variables and group change detection. You would need a stage variable for this field and then set it to the current value when you hit the PROV_TB record and then 'set it to itself' i.e. leave it unchanged for every other row.

As long as you add -wait or -jobstatus, yes.

Everything "Before Job" must complete successfully for the "main job" to run. However, the key question for the second dsjob command is does it use one of the wait options or does it simply start the job without waiting for it to complete?

I wouldn't pass a list of "50 or 101" values as a parameter in a job, you can build a string and do it I just wouldn't recommend it. In your shoes I would load those values to a work table and then change your SQL to be more like: Select * from table where field in (select field from work_...

PCI? Payment Card Industry?

Don't assume everyone knows your acronyms.

Unless you have something installed that lets you run bash scripts on a Windows server?

Must be something, guessing whatever DataStage is using nowadays as those messages are certainly not DOS error messages.

Your link shows the procedure code so you know the "IN" parameters, they are what you need to declare in the stage so it can build a proper anonymous block to call it. Again, it shows you that as well. So each of the four columns in your file get passed to the stored procedure.

Typically one could run something like that in either the "Before SQL" area or the "Open Command" area, depending on the stage, and they would execute before any actual target SQL was performed. I typically trigger these with a 'dummy' source that doesn't actually select any reco...

Involve your official support provider.

Not really sure why they felt the need to heavily redact the screenshot of the job but also didn't really see a need for it to answer the question. IMHO.

Guessing they have some sort of proprietary naming system and they're simply protecting their IP.