Message data conversion

Data conversion is required if you are sending IBM® MQ messages between environments that represent characters and numbers in different ways. For example, you might send messages between operating systems that use different character encoding standards, such as Linux® (ASCII encoding standard) and z/OS® (EBCDIC encoding standard). You might send messages between machines whose locales use different characters, such as German and Japanese. You might also send messages between systems that use a different byte order for numbers. In addition, the format of the message might affect data conversion. For example, IBM MQ messages for CICS® contain a CICS header as well as application data, so must be processed differently from a message that contains just text.

IBM MQ runs its data conversion routines even if data conversion is not required (for example, if you are sending messages between two systems that are alike in terms of data representation). These routines might decide that no work is necessary but an IBM MQ trace always shows the calls to the xcsQueryCCSIDType routines whenever message data is handled in IBM MQ.

Information required for data conversion

When data conversion is required, IBM MQ uses the following pieces of information in the message (or the queue manager that processes the message) to decide what conversion to perform.
Coded character set identifier

The coded character set identifier (CCSID) is a 16-bit number that includes a set of encoding scheme identifiers, character set identifiers, code page identifiers, and other information that uniquely identifies character data. These identifiers are part of an IBM architecture for identifying character data and maintaining data integrity during data conversion processes. For more information about this architecture, including a list of registered CCSIDs, see the Character Data Representation Architecture PDF that is available online.

A CCSID assigns character and non-character data to hexadecimal values ranging from ‘00’ to ‘FF’ (or ‘0000’ to ‘FFFF’ in DBCS (double byte character set) CCSIDs, which are used for alphabets that cannot be represented by 256 positions, such as Kanji). CCSID conversion tables, which are used to convert from one CCSID to another, generally convert character data and control characters. Some well known CCSIDs include 1208 (UTF-8) and 500 (an EBCDID CCSID that is used mainly on z/OS). For a list of supported CCSIDs, see Code page conversion.

Machine encoding

In the context of data conversion, encoding means the method that a platform uses to represent numeric data. The order of the least and most significant bytes in the number can vary depending on the endianness of the platform. For example, z/OS on IBM Z hardware is big-endian (the least significant byte of the number has the highest address and the most significant byte has the lowest address) whereas Windows on x86 hardware is little-endian (the bytes are in reverse order compared to big-endian). So, the number 437 is represented in the hexadecimal system as X’01BF’ on z/OS and as X’BF01’ on Windows. IBM Power® can be either little-endian or big-endian. Numeric data might therefore need conversion even if it is passed between platforms that use the same CCSID.

In IBM MQ, values that represent integer, packed-decimal, and floating-point encodings are combined to produce a single value that represents the machine encoding for the platform. The individual values cover the following machine encodings:
  • Normal (big-endian)
  • Reversed (little-endian)
  • IEEE normal (standard IEEE floating-point format, big-endian)
  • IEEE reversed (standard IEEE floating-point format, little-endian)
  • System/390 (IBM Z floating-point format)
For more information, see Machine encodings.
Format

The format is a name that the sender of an IBM MQ message uses to indicate to the receiver the nature of the data in the message.

IBM MQ has some built-in message formats, which start with MQ. For example, MQFMT_STRING. You can use these formats to indicate that a message contains, for example: a string, CICS data, information about an IBM MQ event, or some programmable command format (PCF) commands for the receiving queue manager to run. You can also define your own formats.

Queue managers might also set the format of a message. For example, when a queue manager cannot deliver a message, it adds a new header at the start of the message, with a format of MQFMT_DEAD_LETTER_HEADER to indicate that the message was not delivered, then puts the message on a dead-letter (undelivered message) queue.

What IBM MQ converts, and why

An IBM MQ message includes the following parts:
  • Message descriptor: identifies the message and contains various control information about it, such as its priority and expiry time, information about the application that sent the message, and information about the application data that is contained within the message (including its CCSID, machine encoding, and format).
  • Application data: the data that the message is being used to send, to be processed by the receiving application.
IBM MQ converts these two message parts independently, for the following reasons:
For channel communication

Each queue manager has a CCSID, which is set automatically when you create the queue manager (though you can modify it afterwards), as described in Creating queue managers on Multiplatforms. When a channel between two IBM MQ queue managers is started, the two queue managers negotiate which CCSID and machine encoding they will use for channel communications. This CCSID and encoding scheme is then used for encoding the IBM MQ transmission segment header (an IBM MQ control block that you might see passed between queue managers if you look at an IBM MQ trace) and the message descriptor. The message descriptor is created and populated by your application when the application puts the message on a queue. Data in the message descriptor must be in the character set and encoding of the local queue manager (as determined by the queue manager's CCSID and the encoding of the local machine) or, if the application is an IBM MQ MQI client application, the character set and encoding of the client system (see Choosing client or server CCSID). IBM MQ needs to understand what the message descriptor contains regardless of the platform that the descriptor was created on, so IBM MQ automatically converts the message descriptor.

The control information in the message descriptor is not all character data; some of the information is converted as character data (according to the CCSID that is in use), some is converted as numeric data (according to the encoding that is in use), and some is passed unconverted, as shown in the following table:
Field Name Field Length in bytes Offset Converted as
StrucId 4 ‘00’x Character
Version 4 ‘04’x Numeric
Report 4 ‘08’x Numeric
MsgType 4 ‘0C’x Numeric
Expiry 4 ‘10’x Numeric
Feedback 4 ‘14’x Numeric
Encoding 4 ‘18’x Numeric
CodedCharSetId 4 ‘1C’x Numeric
Format 8 ‘20’x Character
Priority 4 ‘28’x Numeric
Persistence 4 ‘2C’x Numeric
MsgId 24 (‘18’x) ‘30’x Byte
CorrelId 24 (‘18’x) ‘48’x Byte
BackoutCount 4 ‘60’x Numeric
ReplyToQ 48 (‘30’x) ‘64’x Character
ReplyToQMgr 48 (‘30’x) ‘94’x Character
UserIdentifier 12 (‘0C’x) ‘C4’x Character
AccountingToken 32 (‘20’x) ‘D0’x Byte
ApplIdentityData 32 (‘20’x) ‘F0’x Character
PutApplType 4 ‘110’x Numeric
PutApplName 28 (‘1C’x) ‘114’x Character
PutDate 8 ‘130’x Character
PutTime 8 ‘138’x Character
ApplOriginData 4 ‘140’x Character
GroupId 24 (‘18’x) ‘144’x Byte
MsgSeqNumber 4 ‘15C’x Numeric
Offset 4 ‘160’x Numeric
MsgFlags 4 ‘164’x Numeric
OrginalLength 4 ‘168’x Numeric
Note: The MsgId, CorrelId, Accounting Token and GroupId fields are not considered to be character data, so are not converted as such. Many applications put character data into these fields but if the message is sent between ASCII and EBCDIC platforms and the receiving application needs to be able to read these fields, the application (or a user exit) must convert these fields. IBM MQ does not restrict the format of the data in these fields; if you allow IBM MQ to create the MsgId field, for example, it will not be strictly character data.

For more information about the message descriptor, see MQMD - Message descriptor.

For processing application data so that the receiving application can use it

Generally, IBM MQ does not automatically convert application data because you might want to pass it unconverted (Java applications are an exception, as noted later). Conversion of application data must therefore be requested.

The sending application specifies the CCSID, encoding, and format of the application data by setting the appropriate message descriptor fields before it puts a message onto a queue. The application can specify either actual values or IBM MQ special values, which are strings that indicate, for example, that the data uses the same CCSID as the queue manager that transmits the message, or that the data uses the same encoding as the machine on which the application is running. The application data can also include headers that specify different CCSID, encoding, and format information for the application data that follows the header. For more information about these fields for MQI applications, see the CodedCharSetId, Encoding, and Format sections in Field details for MQMD. (Other application types might have different but equivalent options; for example, applications that use the IBM MQ classes for JMS have the JMS_IBM_Character_Set property, as listed in JMS fields and properties with corresponding MQMD fields.)

The following example IBM MQ message shows that the application data in the message has a CCSID of 850, a machine encoding of 546, and a format of MQEVENT (which indicates that this message contains information about an MQ event):
****Message descriptor****
 
  StrucId  : 'MD  '  Version : 2
  Report   : 0  MsgType : 8
  Expiry   : -1  Feedback : 0
  Encoding : 546  CodedCharSetId : 850
  Format : 'MQEVENT '
  Priority : 0  Persistence : 0
  MsgId : X'414D512073617475726E2E71756575650005D30033563DB8'
  CorrelId : X'000000000000000000000000000000000000000000000000'
  BackoutCount : 0
  ReplyToQ       : '                                                '
  ReplyToQMgr    : 'saturn.queue.manager                            '
  ** Identity Context
  UserIdentifier : '            '
  AccountingToken :
   X'0000000000000000000000000000000000000000000000000000000000000000'
  ApplIdentityData : '                                '
  ** Origin Context
  PutApplType    : '7'
  PutApplName    : 'saturn.queue.manager        '
  PutDate  : '19970417'    PutTime  : '15115208'
  ApplOriginData : '    '
 
  GroupId : X'000000000000000000000000000000000000000000000000'
  MsgSeqNumber   : '1'
  Offset         : '0'
  MsgFlags       : '0'
  OriginalLength : '104'

****  Message   ****

length - 104 bytes

00000000: 0700 0000 2400 0000 0100 0000 2C00 0000 '....→.......,...'
00000010: 0100 0000 0100 0000 0100 0000 AE08 0000 '................'
00000020: 0100 0000 0400 0000 4400 0000 DF07 0000 '........D.......'
00000030: 0000 0000 3000 0000 7361 7475 726E 2E71 '....0...saturn.q'
00000040: 7565 7565 2E6D 616E 6167 6572 2020 2020 'ueue.manager    '
00000050: 2020 2020 2020 2020 2020 2020 2020 2020 '                '
00000060: 2020 2020 2020 2020

The receiving application can request data conversion when the application gets the message from the queue. For example, in an MQI application, request data conversion by specifying the MQGMO_CONVERT option on the MQGET call. The queue manager checks whether conversion is necessary, and if so, converts the data. These checks include, for example, whether the CCSID and encoding in the message descriptor match the CCSID and encoding that the receiving application expects. A receiving MQI application specifies the values that it expects by setting the MsgDesc parameter on the MQGET call. For detailed information about the checks and data conversion processes that MQ follows when a message is received, see Conversion processing.

If the CCSID and encoding of the application data are supported by IBM MQ (see Code page conversion and Machine encodings), and if the format is a built-in IBM MQ format, IBM MQ can perform the data conversion by using its built-in conversion routines. Otherwise, an application programmer must supply the conversion code, in a user exit program known as a data conversion exit. IBM MQ provides skeleton structures and utilities to help you create these user exits. For more information, see Writing data-conversion exits.

Here are some examples of data conversion approaches, depending on the type of data in the message:
The message is entirely numeric data
If the application data is entirely numeric data and you know that the numeric encoding schemes of the two platforms you are passing the message between are the same, the data does not need to be converted. If you suspect that the numeric data encoding schemes of the two platforms might be different, or if you plan for a future when this might be the case, supply a data conversion exit for IBM MQ to use to convert the data.
The message is entirely character data
If the application data is entirely character data, IBM MQ can do the conversion for you. In an MQI application that is sending the message, set the Format field of the MQMD message descriptor to MQFMT_STRING, which is a constant that equates to the string value "MQSTR". This value indicates to IBM MQ that the message consists entirely of character string data.
The message is mixed numeric and character data
If the message is mixed numeric and character data, you must supply a data conversion exit for IBM MQto use to convert the data.
Note: If your application uses IBM MQ classes for Java, IBM MQ classes for JMS, or IBM MQ classes for Jakarta Messaging, data conversion happens automatically in the Java code, for example when you use a Java method to retrieve message text. This difference from other applications, such as C applications, is because a Java application must convert numbers and text between their internal representations and an encoded format for use in messages. Although you can still request data conversion by the queue manager, you might not want to because the data will be converted twice. For information about using IBM MQ classes for Java to process messages, see Handling messages in IBM MQ classes for Java. For detailed information about the data conversion available with IBM MQ classes for JMS and IBM MQ classes for Jakarta Messaging, see JMS message conversion.

Alternatively, a system administrator can request conversion when the message is sent, by setting the CONVERT option on an IBM MQ Sender, Server, Cluster-receiver, or Cluster-sender channel to YES. The message is converted by using the CCSID of the receiving queue manager. Data conversion by message channels is typically used only if it is not possible to use other forms of conversion.

Common practice when putting and getting messages

Regardless of whether the message is character, numeric, or a mixture of both, the following settings are common practice when you write an MQI application to put a message on a queue by using the MQPUT command, and when you get the message by using the MQGET command. For more information about these settings, see Field details for MQMD.
  • Set the MQMD.CodedCharSetId field to MQCCSI_Q_MGR for the message to inherit the CCSID from the queue manager that the application is using. (MQCCSI_INHERIT has the same meaning but can't be used in some scenarios.) This setting is common practice because the CodedCharSetId field in the message descriptor is both an input and an output field. So, if the application is using the same MQMD structure for both MQPUT and MQGET calls, IBM MQ puts the CCSID of every message that it gets into this field. If one of these messages did not use the same CCSID as that of the queue manager, and the application did not convert the message, this field is changed to a value that is not expected when the application does the next MQPUT call. Even if the application did attempt to convert the incoming message, if the MQGET call resulted in an unexpected return code (such as MQRC_TRUNCATED_MSG_ACCEPTED), the message remains unconverted and the CodedCharSetId field is set to the CCSID of the unconverted message.
    Note: In a client application, MQCCSI_Q_MGR refers to the CCSID of the application locale, not the CCSID of the remote queue manager. In all cases, when setting the MQMD.CodedCharSetId field to MQCCSI_Q_MGR, the application must ensure that the CCSID correctly represents the string data that is in the message.
    When an application gets a message from a queue, it should compare the value of the CodedCharSetId field in the message descriptor with the value that the application specified in the MsgDesc parameter of the MQGET call. If the two values differ, the application might need to convert any character data in the message or use a data-conversion exit if one is available.
  • Set the MQMD.Encoding field to MQENC_NATIVE. This setting specifies that the encoding of your message data is the same as that of the machine on which your application is running. When the application gets a message from a queue, it should compare the value of the Encoding field in the message descriptor with the value of the constant MQENC_NATIVE on the machine on which the application is running. If the two values differ, the application might need to convert any numeric data in the message or use a data-conversion exit if one is available.
  • Set the MQMD.Format field according to the nature of the data in your message. Use one of the built-in formats (whose names begin with MQ) or, if none are suitable, you can define your own (the name must not begin with MQ). When you create and use your own formats, you must write a data-conversion exit to support an application getting the message when it specifies the MQGMO_CONVERT option. One of the built-in formats, MQFMT_NONE, indicates that the nature of the data is undefined; IBM MQ does not convert such messages even if the application requests it by specifying the MQGMO_CONVERT option.
  • Convert data when the message is received (for example by the MQI MQGET call) rather than when it is sent (for example, by the MQI MQPUT call). The message might make multiple transfers across different platforms to get to its destination; doing data conversion on each transfer could waste resources, and each transfer risks unexpected channel errors if data conversion fails on the transferring queue manager. However, in some situations, it might be better to convert data when sending the message. For example:
    • If the receiving application cannot convert the message. For example, the application or the receiving queue manager doesn't have the correct character set.
    • When a JMS application sends a message to a non-JMS application. If the message contains text or numbers, it must be converted by the sending application anyway, to change the JVM internal representation of the data into an encoded format for use in the message. If this conversion produces data that can be used by the receiving application, conversion at the receiving end is not required, so this approach is more efficient.
    If you convert when the message is sent and you are using a custom data conversion exit program, that program must reside on the system where the sender channel is defined.
  • If your application is multilingual, you might not know in advance the CCSID of the messages that the application gets from the queue. For example, you might send both Korean and German messages, in ASCII, to an IBM i machine, to be converted into EBCDIC. However, the accented characters of German and the multibyte characters of Korean cannot be represented by a single CCSID in EBCDIC. One solution is to use a separate queue for each language, so that you can specify the appropriate CCSID in the application when it gets a message.

Potential problems

  • The IBM MQ macros, as provided, expect all structures to be packed. However, the C language, on most platforms, tends to put padding characters in structures between character and numeric data, if the boundaries are not on a word boundary. You can address this issue in your application:
    • On IBM MQ for z/OS, declare the data structure as follows:
      _Packed struc_name xxxx
      For more information, see The _Packed qualifier in the documentation for your version of z/OS (for example 3.1.0).
    • On IBM MQ for AIX®, specify the following compiler option:
      -qalign=packed
      For more information, see Aligning data in the documentation for your version of AIX (for example 16.1.0).
    • On IBM MQ for Windows, use one of the following lines as a pragma directive in your code:
      #pragma _Packed or
#pragma pack(1)
      For more information, see the Windows documentation. For example, pack pragma.
  • Avoid the use of the INT and LONG data types because their length depends on the architecture and operating system. Use an IBM MQ data type instead, such as MQINT64 and MQLONG.
  • On UNIX platforms that support both threading and non-threading models, or multiple different threading models, compile your data conversion exit for each model. Otherwise, the exit might not be found if it is called either by different applications or by the IBM MQ channel code (if you specified CONVERT(YES) on your sender channel definition) and you might receive an MQRC_FORMAT_ERROR (2110, x’83E’) error or a message saying that the _r or _d version of the exit could not be found. For more information, see Writing a data-conversion exit for IBM MQ for AIX or Linux systems.
  • If you want to send or get application data in Unicode, some restrictions apply. You must trigger data conversion by specifying a Unicode CCSID in the message descriptor when your application puts or gets a message. Do not trigger data conversion by setting the sender channel CONVERT option to YES because this conversion is always to the CCSID of the receiving queue manager, and queue manager CCSIDs cannot be UTF-16 or, on some platforms, UTF-8. Here are two approaches for using Unicode to support a multilingual application:
    • Convert all your message data to or from Unicode in your client or server, and use IBM MQ as a transport layer. All your client or server processing is done in Unicode. This approach does not use the IBM MQ conversion services and is particularly applicable to clients and servers that have good operating system converters between the Unicode and operating system codepages (for example AIX or Windows).
    • Use IBM MQ to perform the conversion. This approach requires the queue managers at each end to be able to perform conversion to and from Unicode.

    For information about IBM MQ support for Unicode on various platforms, see Unicode conversion support.

  • If you encounter a problem with the conversion of some characters to or from EBCDIC (especially the exclamation point), ensure that the z/OS queue manager's CCSID matches the codepage that the application expects the data in. The fallback CCSID, 500, contains various characters that have different hexadecimal values to those in other EBCDIC CCSIDs. For a list of these differences, see z/OS conversion support. If you encounter such a problem, consider changing the CCSID of the z/OS queue manager by using the CSQ6SYSP macro to set the QMCCSID parameter. For more information, including an explanation of the default CCSID and how you can determine which CCSID is in use, see Using CSQ6SYSP.
  • On AIX, if you get the occasional report of a conversion problem when displaying messages from channels, and your queue manager is running in a non-Latin locale, such as Japanese, the problem might be due to the listener process that is started by the inetd daemon that is running in the C locale. You can avoid this problem by enabling default data conversion or by modifying the program that the inetd daemon calls to a shell script instead. The shell script should set the locale environment variables then call the IBM MQ listener program.
  • Microsoft suggests that programmers should use UTF-8 code pages, as described in the Use UTF-8 code pages in Windows apps article on the Microsoft website. However, applications can use other codepages and Windows supports two groups of system codepages, in which character representation might differ: Windows codepages and OEM codepages. Data conversion problems can occur if an incorrect codepage is used. For example, you might send data that was created by an application in a Windows codepage but the queue manager that sends the data was created with an OEM codepage so the default conversion on an MQPUT call uses a OEM CCSID. Ensure that you specify the correct codepage when you send or get a message. Alternatively, consider changing the CCSID of the queue manager, which might be a better approach if your applications create messages in only one group of codepages.

CCSID conversion tables

On Linux and Windows, conversion tables are provided by IBM MQ. On AIX and IBM i, conversion tables are provided by both IBM MQ and the operating system. Conversion tables that are supplied by IBM MQ tend to provide round-trip integrity; when a piece of data is converted from one CCSID to another and back again, the original data is recovered. Round-trip tables assign a different mapping to every character. If a character exists only in the sending CCSID and not in the receiving CCSID, an arbitrary but unique mapping is assigned to ensure that the conversion process can round trip. A different way of constructing conversion tables is to map all characters that exist in the sending CCSID but not in the receiving CCSID to a substitute character. Such tables do not provide round-trip integrity; when a piece of data is converted from one CCSID to another and back, the original data might not be recovered. Conversion tables that are supplied with the operating system are often of this type. If you require specific handling of unknown characters, consider doing the data conversion within your application by using conversion tables and algorithms that satisfy your requirements.

The location of the operating system CCSID conversion tables varies by operating system. On most UNIX operating systems, you can add conversion tables, generally by adding the binary conversion table file to a specific directory. On other operating systems, such as IBM i, you cannot add extra conversion tables.
IBM MQ for AIX

On AIX, the conversion tables are in /usr/lib/nls/loc/iconvTable.

The converters use codeset names on AIX. These names are usually in the format IBM-xxxx where xxxx is the CCSID number. However, exceptions exist, as listed in the following table:
CCSID Description Codeset name
819 Latin Western European ISO8859-1
912 Latin Eastern European ISO8859-2
915 Cyrillic ISO8859-5
1089 Arabic ISO8859-6
813 Greek ISO8859-7
916 Hebrew ISO8859-8
920 Turkish ISO8859-9
950 TraditionalChinese big5
954 5050 33722 Japanese IBM-eucJP
970 Korean IBM-eucKR
964 Traditional Chinese IBM-eucTW
1383 Simplified Chinese IBM-eucCN
1051 HP-UX Latin IBM-1051
285 German EBCDIC IBM-273
The tables in /usr/lib/nls/loc/iconvTable are used only for SBCS conversions. You can generate these tables by using the AIX genxlt command (for more information about this command, see the relevant topic in the documentation for your version of AIX, for example genxlt Command). IBM MQ for AIX also uses the uconv method for supporting new DBCS (double byte character set) and some SBCS (single byte character set) conversions. The uconv method tables are more complex. You can generate these tables by using the uconvdef command (for more information, see the AIX documentation, for example uconvdef Command). To determine if conversion is supported by the uconv method, do the following checks:
  • Check that the /usr/lib/nls/loc/uconvTable directory (note uconvTable not iconvTable) contains two files, one for the from-codeset and one for the to-codeset.
  • Check that the /usr/lib/nls/loc/iconv directory contains a symbolic link from file from-codeset_to-codeset to file /usr/lib/nls/loc/iconv/Universal_UCS_Conv.
You can use the iconv command to exercise any of the installed conversion tables, for testing purposes. Enter the following command:
iconv -f fromcodeset -t tocodeset fromfile > tofile
Where fromcodeset is the codeset of the fromfile file and tocodeset is the codeset that you want the tofile file to be in.
IBM MQ for Linux
The conversion tables are in /opt/mqm/lib/iconv (where /opt/mqm is the default IBM MQ installation directory).

The conversion code used is similar to Windows.

The tables are named by joining together the hexadecimal versions of the codepage numbers, so conversion from 500 to 850 is in table 01F40352.tbl. In the conversion table directory file, readme.ccs describes most of the shipped tables.

IBM MQ for Windows
The conversion tables are in C:\mqm\conv\table (where C:\mqm is the default IBM MQ installation directory).

The tables on Windows are named by joining together the hexadecimal versions of the codepage numbers, so conversion from 500 to 850 is in table 01F40352.tbl. In the conversion table directory, file readme.ccs describes most of the shipped tables.

Tracing (Windows, UNIX and IBM i)

When looking at trace, a return code of xecX_W_INCOMPATIBLE_CCSIDS x’10806111’or decimal 0276848913 from the function xcsCCSIDCompatible is not an error. This code indicates that the two CCSIDs that were passed into the function are valid but that data conversion is required even for object names. The code should then proceed to call the function to perform this conversion.

When the conversion table is not found, the CCSIDs, and code set names used are shown. During initialization, the trace shows whether default conversion is selected, and if it is, which codepages are selected.

Default data conversion

Default data conversion can be useful if you have a network of queue managers that are working in different national languages, and data conversion among some of the CCSIDs is not supported.

As explained previously, IBM MQ must automatically convert some message data to be able to transfer messages. Conversion between CCSIDs is supported if both CCSIDs relate to a single language or a group of similar languages. If the CCSIDs represent different national-language groups, conversion usually fails with the channel not starting and a conversion not supported message displayed. For example, IBM MQ can convert between CCSIDs 850 and 500 because both apply to Western European languages. IBM MQ cannot convert between CCSID 850 and CCSID 1025 (an EBCDIC coded character set for languages that use Cyrillic script) because many of the characters in one CCSID cannot be represented in the other.

However, the data that is required to process a message, and that flows between channels when they negotiate their connection, is in a very restricted character set: usually A-Z, a-z, 0-9, and a few special characters, as described in Naming IBM MQ objects. To convert this data, IBM MQ needs only to know whether the data uses the ASCII or EBCDIC character encoding standard, then it can use a single table to perform the conversion. This sort of conversion is called default data conversion.

You can enable default data conversion by defining a default ASCII CCSID and a default EBCDIC CCSID. After you define these defaults, if the platform does not have a conversion table from one CCSID to the other but both CCSIDs are known to the queue manager, IBM MQ performs conversion as follows:
  • If the CCSIDs are either both ASCII or both EBCDIC, IBM MQ passes the data to the receiving application unconverted.
  • If one of the CCSIDs is ASCII and the other is EBCDIC, IBM MQ uses the default values to perform the conversion. So, you should use an ASCII/EBCDIC pair that is supported on your platform.

To enable default data conversion, edit the ccsid_part2.tbl file (or the ccsid.tbl file, depending on your platform) to uncomment the two lines that define the EBCDIC and ASCII default values. The suggested defaults are 500 and 850 but you can change these, ensuring that conversion between them is supported. For more information, see the instructions in the file. The change is picked up the next time an application connects to a queue manager (for example, when an MQI application uses an MQCONN call).

The following limitations apply:
  • Default data conversion is not intended for the conversion of application data because it might not do the conversion that you expect. If you want to use default data conversion anyway, you must provide a data conversion exit that enables it. For example, in MQI code, specify the MQDCC_DEFAULT_CONVERSION parameter on the MQXNCVC call. Note that the crtmqcvx command, which you can use to generate data conversion exit code, does not include this parameter.
  • If default data conversion is set, it is used in internal conversions including, for example, the conversion of messages with a message format of MQFMT_STRING.
  • Be careful if you use default data conversion with EBCDIC Japanese CCSIDs 290, 930, 1279, or 5026. The codes that are used for lowercase Latin characters in these CCSIDs are different to any other EBCDIC CCSID (including CCSID 500). Consider setting the EBCDIC default value to 930 or 5026 and the ASCII default value to a CCSID that can be used for conversion to 930 or 5026, such as 932, 94, 954, or 5050. Another alternative when using Japanese EBCDIC CCSIDs is to make sure that all the IBM MQ object names use only uppercase Latin characters.

An alternative approach is to change the CCSIDs of all the queue managers to a single language. Your application data can still use different CCSIDs, as determined by the value that the application sets in the message descriptor.