| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| TDS Problems |
« View previous topic :: View next topic » |
| Author |
Message
|
| cloucas |
 Posted: Thu May 18, 2006 2:25 am Post subject: TDS Problems |
 |
|
Apprentice
Joined: 10 Mar 2006
Posts: 37
|
I am trying to model our messages using TDS, as follows:
Our Mainframe host application currently sends its responses in 4096 (4K) byte blocks, each composed of the message, padded with spaces to 4096 bytes.
The message itself is composed of a Header and a Body. The Header is fixed length, while the Body is composed of an arbitrary number of smaller messages (transactions). Each of the transaction can either be present or absent within the body. There are in total 60 or so different transactions.
Each transaction is itself composed of a number of field delimited elements, each of which can appear from 0 to a few times.
I have developed the above message structure in a message set and am running a test, receiving the following error:
2006-05-18 13:07:04.775014 3720 Error BIP2628E: Exception condition detected on input node 'Response_From_Host_7033.ELS.REPLY.QUEUE'.
The input node 'Response_From_Host_7033.ELS.REPLY.QUEUE' detected an error whilst processing a message. The message flow has been rolled-back and, if the message was being processed in a unit of work, it will remain on the input queue to be processed again. Following messages will indicate the cause of this exception.
Check the error messages which follow to determine why the exception was generated, and take action as described by those messages.
2006-05-18 13:07:04.775207 3720 RecoverableException BIP2230E: Error detected whilst processing a message in node 'Response_From_Host_7033.Trace'.
The message broker detected an error whilst processing a message in node 'Response_From_Host_7033.Trace'. An exception has been thrown to cut short the processing of the message.
See the following messages for details of the error.
2006-05-18 13:07:04.775421 3720 ParserException BIP5421S: Tagged/Delimited String Format (TDS) parsing error
Current message : 'GenericResponse'
Path to current element : '/GenericResponse'
Offset from start of message : 1131
See following errors for more details.
2006-05-18 13:07:04.775578 3720 ParserException BIP5288E: MRM parsing error. Message bit stream larger than expected.
The bit stream of the message being parsed by the MRM parser is larger than expected for a message of this message type.
The message bit stream has been incorrectly constructed, or the logical model is incorrect.
Ensure that the message is correctly packaged.
Any ideas where I am going wrong here? is there a way to model the 4k block anywhere in the message set definition? |
|
| Back to top |
|
 |
| kimbert |
| Posted: Thu May 18, 2006 3:02 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Hi cloucas,
Thanks for the good problem description. This is one of the trickiest TDS errors to diagnose. The actual problem may be quite trivial, but the parsing exception means that you don't get to see the message tree, so you have no idea what happened.
Don't panic, though. There are several approaches:
1. Truncate the input message and see whether you get a successful parse. If you do, then you can inspect the message tree and see what went wrong ( I would start by truncating at byte 1131 and see whether that does the trick )
2. This one takes a bit of work, but always bears fruit in the end.
- Take a service trace while the message is being parsed.
- Read and format the trace. The resulting text file will be huge, but it will contain a complete record of what the TDS parser did with your input message.
- Search for 'BIP5288' in the text file.
- Inspect the trace just prior to the exception being thrown. There will be a lot of clutter, but you should be able to find out which element was the last one to be parsed before the exception was thrown. It probably will not be the one which you expected, and that should point you to the solution.
3. Note : I've never tried this technique, but it ought to work
Set Parse Timing to On-Demand ( its a property of the MQInput ndoe) Put a Compute node immediately after the MQInput node. Select an element which occurs before byte 1131. Write some ESQL which references that element ( DECLARE dummy CHAR; SET dummy = InputBody.Header.myElement; ). Inspect its value using the debugger. You should find that on-demand parsing prevents the BIP5288 from occurring. If the element's value is different from what you expected, you should get a clue about what's going on. If your first choice of element does not yield any clues, try another.
If you're on v6, option 2) is a sure bet. If you're on v5, 1) or 3) is probably better. |
|
| Back to top |
|
|
| cloucas |
| Posted: Thu May 18, 2006 3:18 am Post subject: |
|
|
Apprentice
Joined: 10 Mar 2006
Posts: 37
|
Kimbert
Thanks for your swift response. I am on v5, and I have tried the On-Demand Parsing, but that option is not avalable on my version. Assuming I would like to try option 1, is there an easy way to trucate the message other than writing an application to do so (i.e. is there a utility somewhere that can do this?).
Another question is the 1131...is that including the MQ headers or from the start of the application message? I am using rfhutil to view the message so should I follow the byte count to the left of the display?
Thanks
cloucas |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu May 18, 2006 3:29 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| I have tried the On-Demand Parsing, but that option is not avalable on my version |
My mistake. The option is there in v5, but I was using v6 terminology without thinking. The default behaviour of all the parsers is to do 'on-demand' parsing. It can be overridden in v5 via the Timing property in the Validation settings of the MQInput node, but you don't need to do that.
| Quote: |
| is there an easy way to trucate the message other than writing an application to do so |
TDS messages usually consist of text, so any text editor should be able to do the job. |
|
| Back to top |
|
|
| cloucas |
| Posted: Fri May 19, 2006 2:22 am Post subject: |
|
|
Apprentice
Joined: 10 Mar 2006
Posts: 37
|
Thanks Kimbert
It seems to me that as the error implies, there are indeed more characters in the message than what we have defined in our message set. After the last element, there are about 2000 characters that are padded to produce a total message length of 4096 bytes.
Is there a way to tell the parser to ignore those spaces? Please note that there is no end delimiter and that the last element may contain spaces; the ideal would be having the parser read the last element and its data (could be spaces) up to its defined length and then throw away all padding spaces. |
|
| Back to top |
|
|
| kimbert |
| Posted: Fri May 19, 2006 3:15 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Ah! So you did not model the padding characters. That's why the 'bitstream is longer than expected'. If you can do it, the simplest solution is to read the message as a BLOB and remove the trailing padding characters using SUBSTRING. Then re-parse the trimmed message using the TDS parser.
This will only work if you can be sure that all trailing spaces are padding. Otherwise you might truncate a fixed-length field at the end of your message. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
