If you are exchanging messages between ASCII and EBCDIC platforms, don't use CONVERT(YES) on channels - let the apps request conversion. If the receiving app issues MQGET without MQGMO_CONVERT, you will get the message in whatever format the sending app MQPUT it. If you also need to see the message in converted format after seeing it unconverted, issue the first MQGET with the browse option to get unconverted and then use the MQGMO_MSG_UNDER_CURSOR and MQGMO_CONVERT options for a second MQGET to get in converted format. This method uses MQ facilities, otherwise you have to code the conversion yourself (imho).
Garry.
Our problem is that we don't control the MQGET. It is done by an external application on which we do not have controls.
We are putting the messages onto a remote queue in ASCII format and the external application just reads it off.
Is there any MQ option that we can use to put the messages in EBCDIC format. On the reverse, we need read the message (in EBCDIC format) and get it in ASCII format.
Is there any easy way, using options? Rather than converting the messages before putting them on the Q.
As GFC eluded to, there is always the CONVERT(YES) on the channel. This is not pretty, but it works.
On yet another note, I would question the value of an app that does not know how to MQGMO_CONVERT. What else do they not know how to do? Do they really believe that all of the world is EBCDIC? It doesn't sound like you are playing with a winner here.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.