| Author |
Message
|
| billybong |
 Posted: Tue May 27, 2008 5:39 am Post subject: Diagnosing parsing exceptions without the debugger |
 |
|
Disciple
Joined: 22 Jul 2005
Posts: 150
Location: Stockholm, Sweden
|
Hi guys!
This issue might have been brought up before, but I couldn't find a good way to search for it.
Is it possible to log how far the parsing was successful in a compute node set to parse immediately? What I'm after is to emulate the way the debugger displays a parsing error with writing out exactly the fields it managed to parse and where in the structure the error showed up. I'd like to store this information in the Environment so that a log node could write it out to a file and help to understand where the parsing failed. Our standard routine as of now is to copy the message to the DEV environment and do a debug which takes quite some time and manual labour.
I tried to route the fail terminal of the compute node to another node, but since the message gets rolled back no sign of the failed parsing except for the exception list is stored.
Could this be implemented by i.e. catching the parse exception in a try/catch in the esql?
_________________
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Integration Developer V6.0
IBM Certified System Administrator - WebSphere MQ V6.0
IBM Certified Solution Developer - WebSphere DataPower |
|
| Back to top |
|
 |
| Gaya3 |
| Posted: Tue May 27, 2008 7:44 am Post subject: |
|
|
Jedi
Joined: 12 Sep 2006
Posts: 2493
Location: Boston, US
|
there are lot of ways to find out the exception, use trace node or
start the debug through prompt, try catch node, customize in Error handler flow etc etc.
Regards
Gayathri
_________________
Regards
Gayathri
-----------------------------------------------
Do Something Before you Die |
|
| Back to top |
|
|
| billybong |
| Posted: Tue May 27, 2008 8:45 am Post subject: |
|
|
Disciple
Joined: 22 Jul 2005
Posts: 150
Location: Stockholm, Sweden
|
Yes, the exception is a no-brainer to find since its written in the ExceptionList.
What I'm after is the completed parsing that was successfully parsed before the exception occured. Say i.e. that I parsed a structure to OutputRoot.MRM the debugger might show:
OutputRoot.MRM-
|
- Field A= Somevalue
|
- Field B= SomeotherValue
Parsing failed
So I'm after what I usually get from the debugger in terms of what it actually could create and where the parsing went wrong.
The info in the exception list is quite often not very helpful, especially in the case of an 'MTI Not all buffer was read' error message.
_________________
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Integration Developer V6.0
IBM Certified System Administrator - WebSphere MQ V6.0
IBM Certified Solution Developer - WebSphere DataPower |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue May 27, 2008 10:49 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Hi BillyBong,
Your request is a good one. We have known for a long time that diagnosing parsing exceptions is tricky. Without making promises about the content of future releases, I can at least assure you that the development team are aware of the problem, and intend to address it.
In the mean time, here are my recommendations for diagnosing parsing errors:
- Disconnect the debugger
- Take a user trace. This is especially useful with v6.1 and TDS, because the TDS parser writes useful info into the user trace which tells you ( more or less ) what it has been doing.
- For BIP5288, progressively shorten the input bitstream until you get a successful parse. Then use a Trace node to find out what the tree looks like, or use User Trace to find out what the parser was doing. Or both.
Thanks for taking the time to post a well-considered suggestion. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue May 27, 2008 6:35 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| billybong wrote: |
Yes, the exception is a no-brainer to find since its written in the ExceptionList.
The info in the exception list is quite often not very helpful, especially in the case of an 'MTI Not all buffer was read' error message. |
We have quickly found out that most of our exceptions where we get MTI Not all buffer was read error message had to do with the difference of platform when passing a text msg. Some of our DBA's loaded on Unix an ASCII clob that they FTP'd in binary!... as such we got that nice little msg... a text FTP to load the blob fixed that...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| billybong |
| Posted: Tue May 27, 2008 11:28 pm Post subject: |
|
|
Disciple
Joined: 22 Jul 2005
Posts: 150
Location: Stockholm, Sweden
|
Ok, so I guess there's no easy way to implement this feature yet then.
It's nice to hear that your team is looking into it Kimbert, I'd love to have this feature in a future broker version.
As it is right now you have to be a fairly good broker expert to understand the parsing error codes. My guess is that it would help non-developers tremendously to diagnose parsing errors if they are given a hint of where in the message structure they should start looking.
_________________
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Integration Developer V6.0
IBM Certified System Administrator - WebSphere MQ V6.0
IBM Certified Solution Developer - WebSphere DataPower |
|
| Back to top |
|
|
|
|
