I was wondering whether there is a parallel stage in Datastage that acts as a "tap"? It's like it to take two inputs, one is my nomal data stream, and another uses one value from abother input that acts as a switch to turn on and off data flowing from the first input.
I am using join for this at the moment, but maybe there is some specialised stage for that (a kad a quick look at all other stages but none of them seems to have this funcionality).
"Tap" parallel stage?
Moderators: chulett, rschirm, roy
-
ray.wurlod
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Not a single stage, unless you create your own (Build stage).
The buffering mechanism within parallel jobs handles your requirement non-absolutely - if the producer stage is producing data faster than the consumer stage can process those data, then the buffer "resists" input, effectively slowing down the producer stage.
What are you actually trying to achieve with this job design?
The buffering mechanism within parallel jobs handles your requirement non-absolutely - if the producer stage is producing data faster than the consumer stage can process those data, then the buffer "resists" input, effectively slowing down the producer stage.
What are you actually trying to achieve with this job design?
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
I'm trying to solve the problem described in viewtopic.php?t=142966
The number of reject records should act as a filter for "good" records. If there are no rejects the job finished successfullyt and inserts/updates data in the target table, but if there are some rejects they get logged in reject table and the job aborts.
I implemented the "tap" using join and filter stages and it works now (I will add my comments later to the other thread after I test my job properly). I was just wondering whether I could reduce number of stages....
The number of reject records should act as a filter for "good" records. If there are no rejects the job finished successfullyt and inserts/updates data in the target table, but if there are some rejects they get logged in reject table and the job aborts.
I implemented the "tap" using join and filter stages and it works now (I will add my comments later to the other thread after I test my job properly). I was just wondering whether I could reduce number of stages....