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.
Related
E 02/07/19-07:51:49.358 [-5] JMSListener exception : java.lang.ClassCastException: com.ibm.jms.JMSMessage cannot be cast to javax.jms.TextMessage
This is a ticky one. We put an xml message onto a queue and our code consumed it no problem. The next day, we put another xml message onto the same queue, and the same code threw this error.
I'm looking for suggestions on how to get more info out of what's actually happening, or if anyone else has had intermittent class cast exceptions like this with JMS.
Please note that not all 'XML' messages are sent as JMS TextMessage. I've come across the same thing. Some applications will decide to send you the XML content as JMS BytesMessage (and put the text inside the byte array body). So make sure your sending is really sending you a TextMessage.
One way to see this is to stop your consumer and look at the queued messages with MQExplorer: the Named Property mcd.Msd should show jms_text if it was sent as proper MQ JMS TextMessage. If the data is received from a non-JMS application, the MQ format matters. If the format is MQFMT_STRING, the message is received as a JMS TextMessage. Otherwise, it is received as a JMS BytesMessage !
So either change your publisher to set the value of format to be MQFMT_STRING or change your consumer application to remove the cast to TextMessage and instead also accept BytesMessages and construct the text from the body's byte array.
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.
£ 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.
I'm creating a simple MessageBroker flow. It goes MQInput Node -> Compute -> MQOutput Node where all Compute does is:
CALL CopyEntireMessage();
SET OutputRoot.Properties.MessageFormat='XML1';
It should only change the message format from Binary1 to XML1. However, the MQOutput Node fails and sends the message along its Failure connection. I'm unclear as to the reasons a MQOutput node could fail?
You should check the following points:
Check the parsing options of compute node in the flow (properties--advanced)
Specify the Message set name in the esql.
Specify the output queue name (reply to) in the esql.
check input and output queues are present in the MQ
Check if the function you are calling is there in the esql.
It would be easier to help if you can provide me the failure message.
I've a VB6 application with MQSeries Automation Classes for ActiveX. The problem is when i'm writing the message con the queue. I use this code :
This is how I open the connection and the relative queue :
Set MQSess = New MQSession
//Access Queue
Set QMgr = MQSess.AccessQueueManager(QueueManagerName)
Dim Queue As MQQueue
Dim msg As MQMessage
Dim pmo As MQPutMessageOptions
Dim ArrCar() As Byte
Set pmo = New MQPutMessageOptions
Set Queue = QMgr.AccessQueue(QueueName, OpenOption , RemoteQueueManagerName)
//OpenOption is a integer with value of 16 (MQOO_OUTPUT)
strMsgAppo = Translate("*MESSAGE_TO_INSERT*", ASCII_To_EBCDIC_Table())
ReDim ArrCar(Len(strMsgAppo) - 1)
For lngI = 1 To Len(strMsgAppo)
ArrCar(lngI - 1) = Asc(Mid(strMsgAppo, lngI, 1))
Next lngI
Call msg.Write(ArrCar) //Write the ByteArray
Call Queue.Put(msg, pmo)
The ASCII_To_EBCDIC_Table is a function used to change the encoding.
The error i'm getting from MQ is :
MQAX200.MQMessage::Write CompletionCode = 2, ReasonCode = 2043, ReasonName = MQRC_OBJECT_TYPE_ERROR
Is Anyone using this activex and can help me on how to write message in a queue?
In the code snippet provided, I'm not seeing where the connection to the QMgr is made nor where the queue is opened. Both of these steps must be completed before it is possible to put messages on the queue.
The 2043 reason code occurs when there is an invalid option in the Message Options field for a PUT or an OPEN. In this case the problem could either be on the PUT or an implicit OPEN, depending on what's in the code that was not provided and whether it contains an OPEN.
My suggestion would be to refer to the .Net samples provided in the installation and reconcile between those and your application. The samples reside at C:\Program Files (x86)\IBM\WebSphere MQ\tools\dotnet\samples in a default V7 installation.
The failure is on your msg.Write, and you should probably be using the .WrirteString method instead, after setting the .CharacterSet property to 37 (EBCDIC).
The hackish approach of your Translate() function might work, but only if assigned to a Byte array. As you have things you're likely to see scrambling when the data is converted back to Unicode. Or if Translate() does return a Byte array you'll have a mess with 8-bit data in a Unicode String (which can be fine but not with this MQ library).
You can probably just throw Translate() and your table away.
The IBM manual on this API is called "Using the Component Object Model Interface." Check it out!