| Author |
Message
|
| KIT_INC |
 Posted: Thu Aug 12, 2010 9:00 am Post subject: User exception mqsibackout |
 |
|
Knight
Joined: 25 Aug 2006
Posts: 589
|
I am using WMB 61 CSD 5 on Windows.
I have a simple flow
FileInput - Compute - Fileoutput.
In the compute note I throw an user exception if the data is bad. Everything is working as expected. When the data is bad, an exception is logged in the event viewer and no output is created. However the Inpit file is not moved to the mqsibackout folder. It still get moved to mqsiarchive. Is this normal ? |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Aug 12, 2010 9:06 am Post subject: Re: User exception mqsibackout |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| KIT_INC wrote: |
| Is this normal ? |
AFAIK yes. The mqsibackout folder is used for files that fail validiation within the FileInput node itself. If you're throwing an error further down the file was still successfully processed into the flow so gets archived.
When you say "data is bad" do you mean "fails some business rule"? If you simply mean "doesn't match the expected format" then validating it against the message set in the FileInput node will give the behaviour you're expecting.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Gaya3 |
| Posted: Thu Aug 12, 2010 10:18 am Post subject: |
|
|
Jedi
Joined: 12 Sep 2006
Posts: 2493
Location: Boston, US
|
its normal behaviour of File Input Node 
you have to configure the same in the file input properties,
i am not sure, whether you have done this
there is an attribute called "Action of failing file" in Retry Tab 
_________________
Regards
Gayathri
-----------------------------------------------
Do Something Before you Die |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Aug 12, 2010 11:36 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Gaya3 wrote: |
| there is an attribute called "Action of failing file" in Retry Tab |
The only options for action on failing file are:
Move to mqsibackout (the default)
Delete
Move to mqsibackout with timestamp
What are you suggesting needs to be set to force the file into mqsibackout even if the file has been successfully validated as it has been here? Given that the OP is probably using the default value but even if he isn't the file's not being deleted?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| KIT_INC |
| Posted: Fri Aug 13, 2010 4:06 am Post subject: |
|
|
Knight
Joined: 25 Aug 2006
Posts: 589
|
I have specified in the File input node
Retry mechanism = failure
action on failing file = add time stamp and moved to mqsiback.
Transaction = yes
In the compute node my ESQL is checking for department number, if the department number is not valid, then THROW user exception.
So the file is read in successful by the FileInput node. The compute node ESQL codes do not complete because of the Throw Exception. So there is no output. Should this be consiodered by the borker as failure and move the file to mqsiback ? |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Aug 13, 2010 4:18 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| KIT_INC wrote: |
| Should this be consiodered by the borker as failure and move the file to mqsiback ? |
No, as I said in my original post. The FileInput node considers that a success because the file didn't fail so the file goes to mqsiarchive not mqsibackout.
Unless Gaya3 knows more about the setting of that tab on the FileInput node than I do.
There is of course nothing to stop you catching the user exception in the normal way.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| KIT_INC |
| Posted: Fri Aug 13, 2010 4:46 am Post subject: |
|
|
Knight
Joined: 25 Aug 2006
Posts: 589
|
The description of FileInout node in the 61 info center says
"Use the Retry tab to define how retry processing is performed when a message flow fails:" Action on failing file is under that topic. So this describes action on "When a message flow fail" and not "when the FileInput node fail". Unless a A THROW statement inside the compute node is not considered as message flow failure, my interpretation is the file should be moved to mqsibackout even the fileInput node read in the file successfully. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Aug 13, 2010 5:53 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| KIT_INC wrote: |
| my interpretation is the file should be moved to mqsibackout even the fileInput node read in the file successfully. |
Then you need a PMR. Either the node isn't doing what the documentation says it does (which is wrong) or it's doing what it's intended to do and the documentation doesn't describe that (which is wrong) or the node is doing what the documentation is saying but it's being said in a misleading way (which is wrong).
As a minimum they'll give a better description of "message flow failure" in this context.
Remember I started my first post with AFAIK. I may not know far enough.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| KIT_INC |
| Posted: Fri Aug 13, 2010 6:15 am Post subject: |
|
|
Knight
Joined: 25 Aug 2006
Posts: 589
|
| Thanks Vitor, I will proceed with my support to deal with IBM. I do not have direct IBM support access. So I am seeking help from all the nice persons, like you, in this forum to clarify my understanding before going forward. This forum has been so useful for me. Thanks again to all. |
|
| Back to top |
|
|
| inMo |
| Posted: Fri Aug 13, 2010 6:52 am Post subject: |
|
|
Master
Joined: 27 Jun 2009
Posts: 216
Location: NY
|
| What is the failure terminal on the File Input node wired to? |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Aug 13, 2010 7:34 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| KIT_INC wrote: |
| This forum has been so useful for me. |
We try, and sometimes we fail. And sometimes it really is a bug in the software!
Do post the outcome when you get it if you'd be so good. In the meantime, I repeat my earlier suggestion of catching the error manually as a workround to get you going.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| KIT_INC |
| Posted: Fri Aug 13, 2010 8:20 am Post subject: |
|
|
Knight
Joined: 25 Aug 2006
Posts: 589
|
| Thanks inMo, it's the failure terminal. For the others, I am sorry that I did not mention that the failure terminal is connected. I overlook this myslef too. Everything works as expected after removing the failure terminal connection. We have some exception routine written by other programmers that we need to use. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Aug 13, 2010 8:53 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| KIT_INC wrote: |
| For the others, I am sorry that I did not mention that the failure terminal is connected. |
Ah. That's why the message flow isn't failing. It's successfully diverting the message down the failure leg.
| KIT_INC wrote: |
| Everything works as expected after removing the failure terminal connection |
So I've learned something. My AFAIK is now a little further. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Gaya3 |
| Posted: Fri Aug 13, 2010 10:18 am Post subject: |
|
|
Jedi
Joined: 12 Sep 2006
Posts: 2493
Location: Boston, US
|
over all its not a BUG 
it happens some times..... good learning for us too
_________________
Regards
Gayathri
-----------------------------------------------
Do Something Before you Die |
|
| Back to top |
|
|
|
|
