| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MRM carriage return line feed SWIFT |
« View previous topic :: View next topic » |
| Author |
Message
|
| HugoB |
 Posted: Tue Jul 08, 2003 4:54 am Post subject: MRM carriage return line feed SWIFT |
 |
|
Acolyte
Joined: 26 Jun 2001
Posts: 67
|
Hi, I'm trying to get a subset of the SWIFT MT5XX range in the MRM.
With WMQI 2.1 this is possible (Tagged/Delimited).
I have build up a messageset that will do it, still not 100 % though.
But for some reason i need to put **0d0a** in my test message to force the <CR><LF> as delimiter. But in my test message (without **0d0a**) there is in hex 0D0A (Ultraedit in HEX mode). On other words it's available
in my test message.
(sample)
:16R:GENL
:23G:CAST/A2C4
-}
(end sample)
OK, you don't see it, but in my txt editor there is a carriage return linefeed.
So why do i need to put **0d0a** next to it. So like this;
(sample)
:16R:GENL**0d0a**
:23G:CAST/A2C4**0d0a**
-}
(end sample)
I alos tried to fill in the following in the TDS fields of my compound message (MRM messageset) as delimiter;
<U+000D><U+000A>:
Instead of <CR><LF>:
But this did not change anything.
And the production data is of course also without the additional **0d0a**
Has anyone a suggestion ??? Plz ? |
|
| Back to top |
|
 |
| Lisa |
| Posted: Tue Jul 08, 2003 6:22 am Post subject: SWIFT |
|
|
Master
Joined: 07 Jun 2002
Posts: 287
Location: NJ
|
Hi,
You do not need to add the <CR LF> to the end of each SWIFT tag. I test with SWIFT messages all of the time and I never use them.
Your Data Element Separation should be Tagged Delimited and Delimiter should be <CR><LF>:
Hope this helps,
Lisa
Example test message from my system,
{1:F01PRSHUS33AXXX1827093255}{2:* please do not use *}{4:
:16R:GENL
:28E:00001/ONLY
:20C::SEME//3993-DE313918673
:23G:NEWM
:98A::STAT//20030519
:22F::SFRE//DAIL
:22F::CODE//COMP
:22F::STTY//ACCT
:22F::STBA//SETT
:97A::SAFE//3003271277
:17B::ACTI//N
:17B::AUDT//Y
:17B::CONS//N
:16S:GENL
:16R:ADDINFO
:19A::HOLP//DKK0,
:19A::HOLS//DKK0,
:16S:ADDINFO
-}{5:{MAC:3A87BB4F}{CHK:27CA7BA33BBF}} |
|
| Back to top |
|
|
| HugoB |
| Posted: Tue Jul 08, 2003 6:52 am Post subject: |
|
|
Acolyte
Joined: 26 Jun 2001
Posts: 67
|
Thnx Lisa,
This gives me some confidence that it's not me.
But then again, I have my Data Element Separation Tagged Delimited,
and the Delimiter is indeeed <CR><LF>:.
So I presume it's because of my put tool (mqsiput.exe).
This tool is from ID05 support pac. In which they also put
**0d0a** in their test messages (MT103).
I guess for testing i will stay confronted with this question, and
I hope in later tests, in production, it will be no problem to work
with just plain SWIFT messages without the **0d0a**. |
|
| Back to top |
|
|
| Lisa |
| Posted: Tue Jul 08, 2003 7:48 am Post subject: SWIFT |
|
|
Master
Joined: 07 Jun 2002
Posts: 287
Location: NJ
|
Hi,
It may or may not be your testing tool. I always use RFHUTIL, this tool is very useful. You can put and get message from MQ queues and you can display the message in different formats.
Lisa |
|
| Back to top |
|
|
| Craig B |
| Posted: Tue Jul 08, 2003 8:09 am Post subject: |
|
|
Partisan
Joined: 18 Jun 2003
Posts: 316
Location: UK
|
The MQSIPUT program kindly removes carriage return and line feed characters from your input file. So when the message buffer is formed for the MQPUT, your input message will not contain them, and so this will not parse again definitions that have a <CR><LF> delimiter. As you have found, you can get round this by using the DELIMITER card in MQSIPUT and putting the hex values 0D0A which are not stripped out.
_________________
Regards
Craig |
|
| 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
|
|
|
|
