DSXchange

You should design your job such a way that you lookup the incoming data against the target table to see if the NOTEID's are already existing in the target table. If they exist, you retrieve the Skey (that actually got created in the past when that NOTEID got processed for the first time) from the ta...

harryhome wrote: lookup stage has option to return multilple row only for one reference link. not more for more than one link

So, do you have more than one reference link (which you did not mention in your first post)?

Have you considered using a Remove Duplicates stage?

Did you try doing that in a Transformer/Filter stage downstream?

You could check couple of things:

1. See if the job is in aborted state or Not compiled state as the warning suggests.
2. Are you passing different invocation id's every time you are running the Job Sequence.

How come your Col1 after Transformation 1 is not an empty string but 0? Looks to me that is there is some inconsistency between the logic and examples you have provided.

You can do a lookup on ID field and use a Filter/Transformer Stage downstream to apply the conditions.
Hope that helps.

If my source value for date column is NULL, it don't want to reject that valule in trf stage. You mentioned that you don't want to reject it and again I don't need that record which the Date field is having null value(or no value) in source, just want to discard it. Assuming you want to discard it,...

You will need to define null field values for each column separately.

We are implementing LPAR's at our place and from what I understood from my admin we cannot access datasets from another machine unless they are mounted. I am interested in any alternatives as well.

The error message says it all. The process is using up all the space. How many records are you reading from the reference lookup? Splitting your job might help you avoid this error if you have multiple lookup stages.

Are you connecting to the database on a remote server? If so, you need to invoke the DB2 instance using the environment available.

We have had instances where the RT_LOGnnn files got huge and it slowed the start up times of the parallel jobs literally around 2-4 minutes. We cleared the log files and things came back to normal.

Simple enuf.. huh

Put a copy stage at the end of the output link coming out of the lookup stage. Collect all the records you need via the reject link. Make sure you don't have any output links coming out of the Copy Stage.