| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| TDS writer problem after switch form CSD2 to CSD5 |
« View previous topic :: View next topic » |
| Author |
Message
|
| compute_node |
 Posted: Wed Sep 17, 2003 7:45 am Post subject: TDS writer problem after switch form CSD2 to CSD5 |
 |
|
Newbie
Joined: 17 Sep 2003
Posts: 2
|
Hi, i recently switched from WMQI CSD2 to CSD5 on a test machine.
After this i can no longer use TDS elements of fixed length with repeating compound types like before.
With CSD2 i could write out the compound type with any number of repetitions, even 0.
Now when deploying i get an error that the max occurs parameter ist not set, and if i set it, i have also to define default values for my fixed length elements and end with a lot of empty fields in my message.
I know that the TDS parser cannot parse this kind of format, but the TDS writer could write it with CSD2.
Does someone else have the same problem and mybe a solution for it.
I found some interesting topics concerning similar problems:
Fixed Length Tagged/Delimited Format
http://www.mqseries.net/phpBB2/viewtopic.php?t=10331&highlight=repeat
Repeat value of with TDS? WMQI 2.1 CSD 4
http://www.mqseries.net/phpBB2/viewtopic.php?t=10331&highlight=repeat |
|
| Back to top |
|
 |
| Craig B |
| Posted: Fri Sep 19, 2003 8:58 am Post subject: |
|
|
Partisan
Joined: 18 Jun 2003
Posts: 316
Location: UK
|
Hi,
The change in behaviour you have experienced is as a results of a problem that was fixed from CSD02 to CSD03. In CSD02, you should not have been allowed to deploy a messageSet that contained an unknown number of fixed length repetitions. The TDS wire formant cannot handle an unknown number of fixed repetitions because it would not know where they end. Ie if an element appeared after these unbounded repeating fixed length element/structure, then how would it know where the repetitions end and this next element begins? Therefore the TDS writer needs to write a fixed number of repetitions on the basis that it could have to parse this message again afterwards, and it needs to know how many to parse. The only way to do this is write maxOccurs number of repetitions, hence the model now forces you to fill one in. Obviously if this is the last element in the message definition then it would be useful if the TDS wire format supported this unknown number of repetitions at the end of a message. The TDS parser can cope with this and will parse until the end of the bitstream is reached, however, the TDS writer cannot yet support a repeat until end of bitstream. This is a known requirement for the TDS parser to support.
_________________
Regards
Craig |
|
| Back to top |
|
|
| compute_node |
| Posted: Tue Sep 23, 2003 11:11 pm Post subject: |
|
|
Newbie
Joined: 17 Sep 2003
Posts: 2
|
Hi Craig,
i would not call a problem, but a useful feature. I do not require to parse my TDS format again after i have written it out. One can always produce an unparseable format using TDS, for example by using the same delimter or tag for different kinds of compound types.
I do not want to go back to my old method, cutting pieces out my tree and parsing line by line to blob pieces. There's also the problem of loop count and memory consumptions when using node loops to parse/write and clueing the blobs together.
In one flow i no use an intermediate solution, putting a wrapper compound type arround my fixed lenght line which has a space as delimter and cut the last byte of my line. But this leaves my last byte unusable. This TDS format also would never be parseable again.
Are there other know solutions for writing out an unkown number of repeating fixed length lines (without crlf or other delimters or tags). |
|
| 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
|
|
|
|
