We have a compute node that copies OutputRoot from InputRoot having MQRFH2 header and then sets MQMD format as 'MQSTR ' before sending it to an MQOutput node.
On my local system(MQ and WMB 7.0) when I try to test the flow and browse output queue from RFHUTILC the message still have MQMD format as MQHRF2 with proper MQRFH2 header details.
While this same flow when tested in other test regions is giving an output message with blank MQMD format and RFH2 details comes in message payload.
What can be the reason of this difference?
The input message will have the RFH2 header at InputRoot.MQRFH2, or at InputRoot.MQRFH2C if you use the compact parser for RFH2, which will be copied to the OutputRoot, and Broker sets the MQMD Format to MQHRF2 when it sees that header in the OutputRoot.
To delete the RFH2 header you should do something like this:
SET OutputRoot.MQMD.Format = OutputRoot.MQRFH2.Format;
SET OutputRoot.MQRFH2 = NULL;
I can't think of an explanation for the different behavior you see, and I don't have a V7 Broker to test. By the way you shouldn't have one either as it is out of support.
Related
Could anyone explain how can we reduce total message data send to a topic, like unnecessary message headers. I am trying to send a string of message to a topic and retrieve from that topic using an MQGET call. https://www.ibm.com/docs/en/ibm-mq/9.2?topic=calls-mqget-get-message as defined in this link, datalength is the total size of message received from the topic. The difference of datalength and actual string size is very different. datalength is much more higher than the actual string I am sending.
So it must be that IBM MQ is padding the message with headers and properties which are not required for just sending a string to a topic.
Can we disable the unused headers and properties so that the datalength can come down?
EDIT:
Publisher's side code. here protomsg is the google's protobuf.
string buffer; // message buffer
protomsg.SerializeToString(&buffer);
long n =buffer.length();
char *char_array;
char_array = &buffer[0];
MQPUT(Hcon,
Hobj,
&md,
&pmo,
n,
char_array,
&CompCode,
&Reason);
You can use MQGMO properties options to control which properties are included and whether the properties are returned as message headers or in a separate message handle.
You might want to set the MQGMO_NO_PROPERTIES option, documented here: https://www.ibm.com/docs/en/ibm-mq/9.2?topic=mqgmo-options-mqlong
I have a WTX map which puts a message on WMQ "Q1". There is some other application which reads the message from "Q1" and then processes the message and places the response on the queue specified in "ReplyToQ" available on MQ Header information.
I am not able to find a command parameter to add the ReplyToQ in the message WTX map is placing on "Q1".
Any thoughts?
Thanks for taking the time to look at this question and helping out!
The ReplyToQueue is sent on the message header, so you must get the message with the header (-HDR) and parse it from there on your input card.
Here's the doc about the adapter's command:
http://pic.dhe.ibm.com/infocenter/wtxdoc/v8r4m1/index.jsp
You should have a type tree on the Examples to read the message with a header.
Regards,
Bruno.
£ and ê in a XML message is parsed successfully in broker but when one of the Queue manager tries to put the output message in another Queue manager, It throws 'Unconvertable character' exception and message goes to dead letter queue.
Channel conversion is turned on and CCSID in both the queue managers is set to '819'.
What shall be done to avoid this?
Need Help on this..!!
Update Nov 15
There is more thing that we can check If we are facing this issue.
I was posting the message from RFHUTIL, and in MQMD tab, value in code page field was set to 457. So this was one of the reasons in faillure.
I posted the same message again with code page value as 819 and then the same XML message worked fine.
So, if you are facing the same issue, you might wanna check the RFHUTIL settings as well.
The mentioned characters doesn't come under CCSID 819.
And as the channel conversion is ON, queue manager will try your message to convert the message into it's own CCSID(819), which will fail to do so as the characters are not supported.
Solutions could be:
1) Turn off channel conversion.
2) Change the CCSID of your queue managers to 1208.
Huge topic data conversion, and it depends on the language you use. A general summary is make sure the codedcharsetid for the message in the MD matches the characters codepoints in the message. Then, make sure when you get the message you get/convert and make sure you are either running in a locale which can display those characters OR put a ccsid in the MD prior to the get. If you use .net or Java then there are implications although the same remains true.
We have developed a flow which does a transformation after it gets the data from DB2 stored procedure. While doing the transformation in MAPPING node of wmb v7.0.0.5 we are facing this un convertible recoverable exception. How to avoid this exception to occur.
By default the the CCSID of your broker will be 819. But, I suspect the message you are posting have some characters which are not supported by CCSID 819.
To resolve this issue, you can set the MQMD.CCSID to 1208 as below:
SET OutputRoot.MQMD.CodedCharSetId = 1208;
However, I faced another issue with publication node. The publication node tries to convert the message into the queue manager's CCSID, before publishing. So, if your queue manager's CCSID is 819(lower CCSID than 1208) and publication node tries to convert the message(which contains special characters not supported by CCSID 819), then an exception will be thrown(unconvertible character).
Above case may also hold for mapping node. To resolve this try setting below:
SET OutputRoot.MQRFH2.(MQRFH2.Field)NameValueCCSID = 1208;
SET OutputRoot.Properties.CodedCharSetId = 1208;
If you can put up a trace, then the exact cause will be clear.
What is the address I should use to binding to a queue to a header exchange using Qpid? I want the queue to only receive messages that have a specific header and value?
drain -f "qName ; { create:receiver , node: { durable:False, x-declare: {auto-delete:'false', type:headers}, x-bindings:[{arguments:{x-match:any, 'header1':'value1'},key:qName, queue:qName, exchange:'amqmatch'}]}}"
If your address doesn’t look like this, it will not work. I got an error saying that x-match needed to be included even when I included it.
AMQP Broker: Qpid 0.12