| Author |
Message
|
| girish_tharwani |
 Posted: Sun Mar 29, 2009 2:04 am Post subject: Need help to model this message |
 |
|
Voyager
Joined: 01 Aug 2001
Posts: 88
Location: Pune, India
|
| I need read an XML message from InputRoot and craft a message in OutpurRoot which will be sent to a TCP IP socket program. The outgoing message has 10 fixed length fields (both numeric and string mixed). First and last fields are special. First field is CTRL+B and last is CTRL+C. How to define these in a MRM messageset? Any messageset sample or pointer to documentation will be really appreciated. |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Sun Mar 29, 2009 6:08 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
The terminator (ctrl/c)can be handled in the TCP Output Node as a custom delimiter.
Look at the documentation of the TCP Nodes.
The first character (Ctrl/b) can be handled in MRM by definning a byte character at the start and giving it a fixed value.
as an aside, this is what you get for using a protocol where you don't know how long your data is before you start receiving it. Hence all the buffer overrun vunerabilities that seem to everywhere at the moment.
As a second note, the TCP/IP nodes in 6.1 are far less forgiving that the IA98(?) support pack. I upgraded a system where the message delimiter was 0x0c but the sender actually sent 0x0c0d thus once the message (up to 0c) was processed there was a single character left in the buffer. As this didn't have a delimiter, an error was generated.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| kimbert |
| Posted: Sun Mar 29, 2009 11:58 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Personally I would model the content of the message as a standard fixed-length TDS message, and then add the framing bytes as a separate stage.
And I would not use a message set for the framing bytes - I would write the message to a BLOB and use ESQL to add the framing.
Doing it that way separates the logical structure of the message from the details of the transport. If you have a number of different message formats which all use the same framing bytes, you will find it much simpler to maintain. |
|
| Back to top |
|
|
| girish_tharwani |
| Posted: Sun Mar 29, 2009 9:59 pm Post subject: |
|
|
Voyager
Joined: 01 Aug 2001
Posts: 88
Location: Pune, India
|
Tried smdavies99's approach and it worked. Thanks smdavies99.
kimber, I would like to try your approach also but I have not worked with TDS much. I guess I need to go back to documentation. Any specific document you can refer me? But why TDS, if I leave out the framing bytes, remaining is regular fixedlenght message. |
|
| Back to top |
|
|
| kimbert |
| Posted: Mon Mar 30, 2009 1:33 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
CWF is best for COBOL copybooks. If you are modelling it yourself, I recommend TDS because it provides better diagnostics. The performance is very similar to CWF.
But it's OK to use CWF if that is what you are familiar with, and it does the job. |
|
| Back to top |
|
|
|
|
