Bridge National Language Support

This section describes how the MQ bridge handles messages flowing between MQSeries® systems that use different national languages. The following diagram depicts the flow of a message from an MQe client application to an MQ application.
Figure 1. Message flow from MQe to MQ
Diagram showing a message flowing from a Palm Pilot through an MQe server to an MQSeries server. The flow consists of six stages that are described in detail below. The language transformation takes place at stage four, in the MQe-MQ bridge on the MQe server.
  1. Client application
    1. The client application builds an MQe message object containing the following data:
      A Unicode field
      This string is generated using appropriate libraries available on the client machine (if C/C++ is being used).
      A byte field
      This field should never be translated
      An ascii field
      This string has a very limited range of valid characters, conforming to the ASCII standard. The only valid characters are those that are invariant over all ASCII code pages.
    2. The message is put to the Palm queue manager. No translation is done during this put.
  2. Client queue manager puts to the server queue manager

    The message is not translated at all through this step.

  3. MQe server puts the message onto the MQ bridge queue

    The message is not translated at all through this step.

  4. MQ bridge passes the MQe message to the user-written transformer
    Note: The examples in this section are in Java™ because transformers can only be written in Java. Refer to Developing a basic application for more information.
    The transformer creates an MQ message as follows:
    • The Unicode field in the MQe message is retrieved using:
      String value = MQemsg.GetUnicode(fieldname)
    • The retrieved value is copied to the MQ message using MQmsg.writeChars( value )
    • The byte field in the MQe message is retrieved using:
      Byte value = MQemsg.getByte(fieldName)
    • The retrieved value is copied to the MQ message using MQmsg.writeByte(value)
    • The ascii field in the MQe message is retrieved using either MQmsg.writeChars(value) to create a unicode value, or MQmsg.writeString( value) to create a code-set-dependent value, in the MQ message.
    If using writeString(), the character set of the string may also be set. The transformer returns the resultant MQ message to the calling MQ bridge code.
  5. The MQ bridge passes the message to MQ using the MQ Classes for Java

    Unicode values in the MQ message are translated from big-endian to little-endian, and vice versa, as required. Byte values in the MQ message are translated from big-endian to little-endian, and vice versa, as required. The field that was created using writeString() is translated as the message is put to MQ, using conversion routines inside the MQ Classes for Java. ASCII data should remain ASCII data regardless of the character set conversions performed. The translations done during this step depend on the code page of the message, the CCSID of the sending MQ Classes for Java client connection, and the CCSID of the receiving MQ server connection.

  6. The message is got by an MQ application

    If the message contains a unicode string, the application must deal with that string as a unicode string, or else convert it into some other format (UTF8 , for example). If the message contains a byte string, the application may use the bytes as it is (raw data). If the message contains a string, it is read from the message, and may be converted to a different data format as required by the application. This conversion is dependent on the codeset value in the characterSet header field. Java classes provide this automatically.

Conclusion

If you have an MQe application, and wish to convey character-related data from MQe to MQ, your choice of method is determined largely by the data you wish to convey:

  • If your data contains characters in the variant ranges of the ASCII character code pages, the character for a codepoint changes as you change between the various ASCII code pages, then use either putUnicode, which is never subject to translation between code pages, or putArrayOfByte, in which case you have to handle the translation between the sender's code page and the receiver's code page.
    Note: DO NOT USE putAscii() as the characters in the variant parts of the ASCII code pages are subject to translation.
  • If your data contains only characters in the invariant ranges of the ASCII character code pages, then you can use putUnicode (which is never subject to translation between code pages) or putAscii, which is never subject to translation between code pages, as all your data lies within the invariant range of the ASCII code pages.

Terms of use | WebSphere software

(c) Copyright IBM Corporation 2004, 2005. All rights reserved.