| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| TDS Carriage Return Line Feed remain in data after parsing |
« View previous topic :: View next topic » |
| Author |
Message
|
| smeunier |
 Posted: Mon Sep 12, 2011 2:09 pm Post subject: TDS Carriage Return Line Feed remain in data after parsing |
 |
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
I receive a file, which as CRLF after each line of data. My message set is contructed to parse the data into groups (Header,Details(+1),Trailer). There can be multiple group of this data. This all works fine, each Group(s) are broken down properly. The issue, is that the last data element in each line always has the \r appended to it. There is a \r\n at the end of each line of data in the input. Only the \r appears not the \n. In the message set at the root I have "All Elements Delimited" and specify the <CR><LF> mnemonics at the delimiters. My reading lead me to beleive that the \r\n would be stripped off by the parser is using this option. The \n appears to be, but not the \r.
Root - Data Element Separation: All Elements Delimited Delimiter:<CR><LF>
Children - Data Element Separation: Tagged Delimited
Delimiter: <CR><LF>
Any ideas on how to rid the \r? |
|
| Back to top |
|
 |
| kimbert |
| Posted: Tue Sep 13, 2011 11:31 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Are you 100% sure that the data is terminated by \r\n. Is it possible that the line terminator in the input data is \r\r\n - that would produce exactly the effect that you are describing.
Next steps:
- inspect the raw bytes of the input message, and check what the line terminator really is
- double-check that the delimiter for the outermost group is <CR><LF> and not just <LF>.
If all you are still stuck, do this:
1. Cut down your message set so that it parses each line as a single string field.
2. Verify that the problem still happens ( i.e. the single string field always ends with \r ).
3. Insert a Trace node after the input node.
4. Take a user trace, and post the result here. Post the mxsd file as well - it should be very small. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Sep 13, 2011 11:34 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Also, if the payload is coming from a different system architecture, the transfer of the file may be set to binary rather than text. This would produce an extra \r in some cases.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| smeunier |
| Posted: Tue Sep 27, 2011 1:25 pm Post subject: |
|
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
Sorry for the lag in response on this. After doing some further investigation with helpful hints from "kimbert" I found that the data stream coming in was being handled by another flow, which insured the length of each record was 512 bytes, thus separating the 0d from the 0a as it looked for the 0a as the terminator to determine where to pad the data (legacy stuff). Once I saw this, then I knew the data would get parsed correctly when it came from it true source (AS/400). Or so I thought. The file I was using as direct input to the queue (from windows) now parses OK and I can reconcile the \r because Windows uses a 0d0a as a line terminator. Given this, I figured, once the data came directly from AS/400 (just 0A terminator), things would be honky dory.
Now even though the data stream is correct(0A terminated), the parser now fails (step backwards) when sent from AS/400 directly as input into the queue (as opposed to when I read the file into the queue). This is a little puzzling to me.
The model is:
| Code: |
- EDI846 <Local Complex Type>
- Local Complex Type Data Elem. Separation: VLED Delimiter <LF>
- PRGROUP <Local Complex Type> Min(1) Max (-1) Repeating Delim <LF>
- Local Complex Type Data Elem. Separation: Tagged Delimited Delimiter: <LF>
- SEG1 Tag:H
- SEG2 Tag:D Repeating Delim.: <LF>
- SEG3 Tag:T |
As mentioned, when file read into queue from Window, it parse OK, when received from AS/400 it fails with:
PRGROUP: The parent of this child or group has a Data Element Separation of 'All Elements Delimited' or 'Variable Length Elements Delimited'. All complex children with type or group with a Data Element Separation of 'All Elements Delimited' or 'Variable Length Elements Delimited' should be followed by some markup. That is a 'Repeating Element Delimiter', 'Delimiter', 'Group Terminator' or some markup from a higher level in the message model.
I think/thought I meet all this?!
Little confused on why it parses OK one way but no the other.
- local Complex type |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Sep 28, 2011 12:48 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
... not in [c o d e] tags 
Next step is to diagnose the problem - debug-level user trace works well for that. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Sep 28, 2011 5:52 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| kimbert wrote: |
... not in [c o d e] tags
|
Now it is 
_________________
MQ & Broker admin |
|
| 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
|
|
|
|
