Application data conversion

When necessary, MCAs convert the message descriptor and header data into the required character set and encoding. Either end of the link (that is, the local MCA or the remote MCA) can do the conversion.

When an application puts messages on a queue, the local queue manager adds control information to the message descriptors to facilitate the control of the messages when they are processed by queue managers and MCAs. Depending on the environment, the message header data fields are created in the character set and encoding of the local system.

When you move messages between systems, you sometimes need to convert the application data into the character set and encoding required by the receiving system. This can be done either from within application programs on the receiving system or by the MCAs on the sending system. If data conversion is supported on the receiving system, use application programs to convert the application data, rather than depending on the conversion having already occurred at the sending system.

• The CodedCharSetId or Encoding fields set in the MQMD structure associated with the message on the queue differ from the CodedCharSetId or Encoding fields set in the MQMD structure specified on the MQGET call.
• The Format field in the MQMD structure associated with the message is not MQFMT_NONE.
• The BufferLength specified on the MQGET call is not zero.
• The message data length is not zero.
• The queue manager supports conversion between the CodedCharSetId and Encoding fields specified in the MQMD structures associated with the message and the MQGET call. See CodedCharSetId and Encoding for details of the coded character set identifiers and machine encodings supported.
• The queue manager supports conversion of the message format. If the Format field of the MQMD structure associated with the message is one of the built-in formats, the queue manager can convert the message. If the Format is not one of the built-in formats, we need to write a data-conversion exit to convert the message.

If the sending MCA is to convert the data, specify the CONVERT(YES) keyword on the definition of each sender or server channel for which conversion is required. If the data conversion fails, the message is sent to the DLQ at the sending queue manager and the Feedback field of the MQDLH structure indicates the reason. If the message cannot be put on the DLQ, the channel closes and the unconverted message remains on the transmission queue. Data conversion within applications rather than at sending MCAs avoids this situation.

As a rule, data in the message that is described as character data by the built-in format or data-conversion exit is converted from the coded character set used by the message to that requested, and numeric fields are converted to the encoding requested.

For further details of the conversion processing conventions used when converting the built-in formats, and for information about writing your own data-conversion exits, see Writing data-conversion exits. See also National languages and Machine encodings for information about the language support tables and about the supported machine encodings.

Conversion of EBCDIC newline characters

For to ensure that the data that you send from an EBCDIC platform to an ASCII one is identical to the data that you receive back again, we must control the conversion of EBCDIC newline characters.

We can do this using a platform-dependent switch that forces IBM MQ to use the unmodified conversion tables, but we must be aware of the inconsistent behavior that might result.

The problem arises because the EBCDIC newline character is not converted consistently across platforms or conversion tables. As a result, if the data is displayed on an ASCII platform, the formatting might be incorrect. This would make it difficult, for example, to administer an IBM i system remotely from an ASCII platform using RUNMQSC.

See Data conversion for further information about converting EBCDIC-format data to ASCII format.