I created a test job:
Seq_1 --> xfm --> Seq_2
Seq_1:
Uses filters
/dev/null
echo "AAA"
xfm:
Straight pipe to Seq_2
Seq_2:
Output file /dev/null
This compiled and ran fine.
I then added a reject link writing to Seq_3, where the output file is /dev/null.
This job compiled OK but experienced a run time abort.
So, it appears I can write to /dev/null on an output file, but not a reject link.
Which begs the question, why?
In my "real" job, the output target is a DRS stage (SQL Server). I need to do something if the write(s) (across several output links) are successful, and not do that something if the write was rejected for any of the links.
I'm not concerned with capturing anything in the reject file - I'm happy with whatever gets written to the DS log.
When I click Constraints, Expression Editor Context Help ("..." button), Link Variables, Outputs..., I see what looks to be a global REJECTED variable, and individual link REJECTED variables.
If there is a way to set the REJECTED variables without having a Reject link (Reject Row box ticked), please let me know.
Thanks...
Can I write to /dev/null on a reject link?
Moderators: chulett, rschirm, roy
Re: Can I write to /dev/null on a reject link?
Sure - logically reject it via the constraint. As you've noted, one of the ellipses options is simply 'REJECTED', meaning if it hasn't gone down any previous link yet, go down this one. This is the same as what happens when you click the 'Reject row' option minus the logging of a warning with the count of rejected records.sbass1 wrote:When I click Constraints, Expression Editor Context Help ("..." button), Link Variables, Outputs..., I see what looks to be a global REJECTED variable, and individual link REJECTED variables. If there is a way to set the REJECTED variables without having a Reject link (Reject Row box ticked), please let me know.
You can also do it based on the record being rejected by a specific link: linkname.REJECTED or linkname.REJECTEDCODE with the first being a Boolean and the second if you actually care why it was rejected.
Don't forget that these checks are positional, so make sure your links are ordered properly to support them.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
ps. There's no need to "set" them, that's handled in the generated code, something you could check out if you are curious in the RT_BPnnn directory for your job. So just reference them in your "reject" links.
Oh, and rejected means not only "didn't go down" but "didn't stay down" as well, so can catch rejects spit back by a database for instance.
Oh, and rejected means not only "didn't go down" but "didn't stay down" as well, so can catch rejects spit back by a database for instance.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
Thanks. Yes that's what I meant but didn't word well. I meant "If there is a way to ensure the REJECTED variables are set by DataStage without having a Reject link..."chulett wrote:ps. There's no need to "set" them, that's handled in the generated code
I could swear I had a situation where I had a Rejected row link, another link (updating a hashed file) where the constraint was Not(REJECTED), and this was the last link, but was still getting output rows when the row was rejected by the database (violate null constraints).
I'll play with this further once I'm back in the office.
Thanks again...
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
The REJECTED variables are always set. Take a look at the code generated for the Transformer stage, in the RT_BPnnn directory in the project directory on the server.
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.
My job output links consisted of (in this order):sbass1 wrote:I could swear I had a situation where I had a Rejected row link, another link (updating a hashed file) where the constraint was Not(REJECTED), and this was the last link, but was still getting output rows when the row was rejected by the database (violate null constraints).
1) Update old record
2) Close out old record
3) Insert new record
4) Reject to seq file if any of the above three failed (reject row ticked)
5) Update CRC hashed file only if there were no rejects (constraint = Not(REJECTED) )
But the hash was still getting updated even when there were rejects.
The problem was, the write to the reject file wasn't a reject. It was successful! Which reset the global REJECTED flag.
When I re-ordered #4 and #5 the code worked as expected.
HTH...
While it has been ages since I looked at them, my understanding of the reject link is to take all records that do not satisfy the constraints of the other links. From this, the reject link has to be the last link. Maybe its process has changed...
Assuming it hasn't changed, your "reject" link should have an inverse constraint (i.e. where does not meet one of the other three) and your update hashed file is updated if any other the three were updated
Assuming it hasn't changed, your "reject" link should have an inverse constraint (i.e. where does not meet one of the other three) and your update hashed file is updated if any other the three were updated