| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| CARDINALITY(InputRoot.MRM.T222R121[]) in version 6 |
« View previous topic :: View next topic » |
| Author |
Message
|
| Bartez75 |
 Posted: Fri Nov 17, 2006 3:58 am Post subject: CARDINALITY(InputRoot.MRM.T222R121[]) in version 6 |
 |
|
Voyager
Joined: 26 Oct 2006
Posts: 80
Location: Poland, Wroclaw
|
Do you know if this line:
| Code: |
| SET MAXREC = CARDINALITY(InputRoot.MRM.T222R121[]); |
will work in version 6? I have a problem with this? I got this error:
<Text>Error detected, rethrowing</Text>
- <Insert>
<Type>5</Type>
<Text>.T214_RESTCOS2OM_ChNbrSignal_MRM2XML.main</Text>
</Insert>
- <Insert>
<Type>5</Type>
<Text>23.3</Text>
</Insert>
- <Insert>
<Type>5</Type>
<Text>SET MAXREC = CARDINALITY(InputRoot.MRM.T222R121[ ]);</Text>
</Insert>
- <ParserException>
<File>F:\build\S600_P\src\MTI\MTIforBroker\MtiImbParser2\MtiImbParser.cpp</File>
<Line>614</Line>
<Function>MtiImbParser::parseRightSibling</Function>
<Type>ComIbmComputeNode</Type>
<Text>TDS General Error</Text>
- <Insert>
<Type>5</Type>
<Text>IDRT</Text>
</Insert>
- <Insert>
<Type>5</Type>
<Text>/T222R121_BLOB/T222R121/IDRT</Text>
</Insert>
- <Insert>
<Type>2</Type>
<Text>237</Text>
</Insert>
- <ParserException>
<File>F:\build\S600_P\src\cpi\pwf\nxd\nxdscanner.cpp</File>
<Line>103</Line>
<Function>NXDScanner::extractFixedLengthData</Function>
<Type />
<Name />
<Label />
<Catalog>BIPv600</Catalog>
<Severity>3</Severity>
<Number>5426</Number>
<Text>Not enough data in bitstream</Text>
</ParserException>
The strange thing is that when I'm debuging the flow the it is ok. It is also working in the flow deployed to broker version 5. Is my MRM now somehow wrong?I haven't done any changes there, just clean the project and rebuild it. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Fri Nov 17, 2006 4:56 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
What the error is telling you is that Broker is trying to parse the entire message, and the bitstream ended before the model said it should.
This could be because this is the first time you've caused a full parse on the bitstream.
Try putting a trace node before this compute node, with the ${Root} pattern, and see if it also throws the same problem.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kimbert |
| Posted: Fri Nov 17, 2006 8:58 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Looks as if you have found a change of behaviour between v5 and v6. You can follow two routes from here:
- Raise a PMR or
- Provide some details of your message model to me (via this forum) and see whether we can sort it out quickly via a small change to your message model.
I suggest we follow option 2 for a couple of days, and fall back to option 1 if we cannot solve it fairly quickly. |
|
| Back to top |
|
|
| Bartez75 |
| Posted: Tue Nov 21, 2006 8:44 am Post subject: |
|
|
Voyager
Joined: 26 Oct 2006
Posts: 80
Location: Poland, Wroclaw
|
Hi
I have solved it by changing max occurs of element from 5000 to -1.
What if I would like to have 1000 but maybe in that case it will be a different message set, I don't know. This is ok for me becaues there could from 1 record to * records.
Properties of type for that element looks like that:
Comlex Type:
Content: Local Group
Composition: sequence
Content validation Closed
Min Occurs: 1
Max Occurs: -1
Physical properties->TDS1->Complex Type:
Data Element Separation: Fixed Length
Grup Indicator: empty
Group indicator: empty[/img] |
|
| 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
|
|
|
|
