This question already has an answer here:
Is there an MQ/XMS equivalent for the MQ/JMS setTargetClient
(1 answer)
Closed 3 years ago.
We have written a .NET application using IBM MQ XMS which listens to a queue, inspects message contents and then forwards messages to the correct queue. The message is forwarded unmodified.
BizTalk picks the message up but is leaving it in an Unparsed Interchange format with message header information in the body. Example:
RFH ... MQSTR ... <mcd><Msd>jms_text</Msd></mcd> d <jms><Dst>queue:///VC.AZ.BT.270.Q.5010?persistence=1</Dst><Tms>1575310018071</Tms><Dlv>1</Dlv></jms>
<usr></usr> ISA*00*...
If we bypass the .NET routing client and drop a message directly onto the same queue from MQ Explorer, BizTalk parses it into a Serialized Interchange format as expected. We cannot see why this header info is not being parsed out. Any ideas?
Your .Net code is likely tripping significant NULLs or other non-visual characters. BizTalk will require the message to have all characters accounted for in the message header or it will fail. Use a tool like Notepad++ or UltraEdit to inspect the messages in HEX mode to be able to pinpoint where the difference is. What is the purpose of the routing client? Where is it in the message flow? Why not use BizTalk for the routing and cut out the offending program?
Related
Has anyone worked with MQ from RPG?
The problem is as follows. There are several messages in the queue. All of them are with RFH2 header. Each header contains a set of NameValueData.
I am creating a Message Handle and passing it to MQGET. Then I retrieve Properties using MQINQMP.
Question. When I read several messages in a loop, using the same Message Handle instance for all (without freeing it and re-creating it for each message), will I have memory leaks?
The IBM MQ Message Properties API is designed to be used in the following way.
MQOPEN
MQCRTMH
start-loop
MQGET
MQINQMP
end-loop
MQCLOSE
MQDLTMH
You can see this demonstrated in the IBM supplied 'C' sample amqsbcg0.c. I know your question is for RPG, but the underlying API is meant to work the same for all languages.
I would like to test some MQ-related functionality and I wanted to use MQ Explorer (v 7.5.0.2) to put a message to MQ queue. However, the input field accepts only one line messages
Is it possible to put multi-line messages using MQ Explorer? Using sequences like \n or
does not work.
It is sad, but currently IBM MQ Explorer does not allow to send multiline message.
My workaround to this is to use JMSToolBox:
https://github.com/jmstoolbox/jmstoolbox
General description how to set it up with IBM MQ is here:
https://github.com/jmstoolbox/jmstoolbox/wiki/2.1-Setup-for-IBM-MQ
In my case two extra jars were needed:
com.ibm.mq.allclient-9.2.4.0.jar
json-20210307.jar
My problem is: there is an application, that wants from me XML messages with ISO-8859-2 encoding. Currently I use IBM MQ Explorer 9.0, and there are two queues in a queue manager. Either of them use I to put the XML message manual:copy XML->select queue->right click->put test message->paste the XML in the inputfield->Put.
(The other one is the queue, where the response messages are).
When I put an XML message with these ISO-8859-2 encoding, the "ő" and "ű" characters change to another characters. Actually, the application, that reads the XML messages from this queue, uses ISO-8859-2 encoding, and it gets this message with the bad "ő", "ű" characters (õ, û).
The message doesnt pass between queue managers. I dont know the application, that the message reads from the queue. They said, they want the XML messages with ISO-8859-2 encoding.
When I put the message, and click to "browse messages" by the queue, and I see the message properties, the 'character set id' is 1208. I think, it must be 912. Isn't it the problem? How can I change it?
This is the message data properties, that I put to the queue:
And we get the message with these properties:
Thanks
Recently I attended an interview, he asked this question
I am putting messages in Q. Manager, but client unable to get that messages, what is the problem can you explain it?
(All permission are ok, and put and get are enable state).
There are a 101 possible reasons. That is why MQ provides an MQRC back to the application, and further information in the AMQERR01.LOG. Without either of those you cannot even begin to guess. (P.S. I suspect that would have been a suitable reply in an interview!!)
But, since you ask for us to guess, here's a few more different from those Valerie suggested.
Perhaps the client channel max message length is shorter than the messages on the queue.
The codepage between client and queue manager may be such that data cannot be converted.
Client application get buffer isn't big enough
Hasn't specified accept truncated and the message was bigger than the buffer
AMS is in use and he's not the intended recipient (different from permissions)
This is a very broad question, would need to check error code received by client. Could be programming situation where client is getting based on a specific message or correl ID that does not exist. Could be that channel auth is blocking client. Also, it could be that the putting application did not commit the messages so they are not really available for the get.
Recently I got an application request :
A sends orders to T via MQ. The messages sent by A use CCSID 500.
While recieving the order at T end most of the orders are in CCSID 500 format. But some of the orders have their CCSID changed to 1047.
When this is the case A-T interface stops and the orders have to be manually inserted into the databse.
Can you advise us under what circumstances this CCSID could change? And is there any configuration changes that could be made either at T or A side to prevent this happening ?
The CCSID is set by the application that does the MQPUT.
When it is left empty then it is filled by the underlyingin MQ installation.
The MQGET application can set a message get option to convert it to a desired CCSID.
There are tables in the appendix of the "application programming reference" in Knowledge center for all possible translations.
If you are dealing with MQFMT_STRING messages, you should be able to use GMO_CONVERT so all the messages get converted to the CCSID on the T side.
You may have an issue with missing translation tables on the receiving side. Check in the MQ installation directory /IBM/WebSphere MQ/conv/table.
Here's a little note from IBM describing the differences between EBCDIC code pages: https://www.ibm.com/support/knowledgecenter/SSEPEK_10.0.0/com.ibm.db2z10.doc.char/src/tpc/db2z_codeptdiffebcdic.dita
Source: http://www-01.ibm.com/support/docview.wss?uid=swg27005729