Hello,

We have a Cobol program that puts a message containing XML data onto a remote queue defined on a z/OS queue manager (CCSID 37). The local queue resides on a distributed queue manager (Solaris, CCSID 819) and the sender channel from z/OS has data conversion set to YES.

The distributed consumer application, which uses WAS, is all of a sudden complaining that their data in no longer being converted from 037 to 819. Of course, the producer and consumer applications claim that nothing has changed in years. From the MQ administration side, nothing has changed with their object definitions and the infrastructures remain the same.

On z/OS, I was able to capture the messages from the cobol program on a local queue so that I could check the MQMD header with MQ Explorer. The message format of them is blank (MQFMT_NONE), CCSID 37, and an encoding of 785. The Message Data is also readable.

On Distributed MQ, the messages have the same MQMD header but the Message Data is in binary.

Should the sender channel be converting the data to a 819 code page? My guess is that the answer is no because the producer application is putting the messages as MQFMT_NONE. If true, the consumer application has always been doing the data conversion and something must have changed in their code or configuration.

We have spent a lot of time trying to debug this conversion issue and it's become a finger pointing game so I would appreciate any advice or suggestions that you may have!

A binary message, that is one with a format of MQFMT_NONE, is never converted by MQ.

Normally an XML message would have a format of MQFMT_STRING.

I can't think of anything you can do administratively to change the format from string to binary. I would be inspecting the putting application to see why it is no longer sending a string message.

Cheers,
Morag

Thank you, Morag! 

The Cobol program that creates the XML content and puts the message onto a queue was last compiled a few years ago. It does not specify any format in its code so the messages are being put in the default binary format. The producer application team is challenging my suggestion to use MQFMT_STR because “nothing has changed in years.”

Since MQ will not convert a binary message, does that mean that the consumer application must be doing a GMO_CONVERT? Is a user exit also required since it is binary data? 

Regards,

Nate

When I said "MQ will not convert a binary message" I meant in both the case of CONVERT(YES) on the channel and in the case of an application using MQGMO_CONVERT. If the consumer application asks for MQGMO_CONVERT it is requesting that MQ does data conversion if it is needed. MQ believes it is not needed for a binary message.

It is somewhat of a mystery how your message was converted before - perhaps the consumer used to do it, or perhaps there was some exit, but the simplest fix, if no-one will admit to changing anything downstream would seem to be to provide a string message.

Otherwise, the detective in you will have to track down what has changed when everyone claims nothing has changed :-)

Cheers,
Morag

One thought - Java has built in data conversion too, which sometimes can be used instead of MQ's data conversion.

Since your consumer is running in WAS, which is Java, what changed in that environment recently?

Cheers,
Morag

This is definitely like finding a needle in a haystack! Im hoping to convince the producer application to use MQFMT_STR so that we can just let the sender channel handle the conversion since it’s already enabled (less changes).

I don’t have any distributed access so it’s hard for me to investigate the consuming application but it’s time that I challenge their configuration further. Thank you for your help!

I wish you the best of luck.

I have a new data conversion issue, I think.

My older QMgr on RHEL5, was v75 with CCSID=819.  Customers were happy.

Last night I created a new v8008 QMgr on  a RHEL7 and the CCSID is now 1208.

Existing older MQ objects were ported in from old QMgr and fed into new QMgr (no system objects or qmgr defs.)

One customer started complaining that their messages were garbage.

Their messages comes in from 3rd party vendor QMgr v7000150.  3rd party say they did not change anything.

These3 messages come in to the new QMgr and go directly to an XMITQ, then a SDR channel sends them on to the z/OS Mainframe.  This SDR channel has NO CONVERSION, same as on the older QMgr. 

So, I am thinking, to make this one customer happy, I should change the 1208 CCSID to 819 on the new v8 QMgr.

Make sense?

Marge,

The 819 and 1208 represent different character sets and I would expect different conversion issues with the change.  The reason is that the application running on UNIX is generating data in the UNIX CCSID and MQ is "mislabeling" the data when an incorrect CCSID is specified.  If 819 was working before, changing your Queue Manager setting and restarting the Queue Manager will probably do the trick.  

For your reference:

819 (ISO 8859-1 ASCII)
1208 (UTF-8 with IBM PUA)

Here is a link to the IBM CCSID meanings:    IBM CCSIDs

IMPORTANT:

Here is a link to determine the proper CCSID on UNIX:    IBM Tech note to determine MQ CCSID on UNIX

Regards,

Glen Brumbaugh