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
Client application
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.
The message is put to the Palm queue manager. No translation is done during
this put.
Client queue manager puts to the server queue manager
The message
is not translated at all through this step.
MQe server puts the message onto the MQ bridge queue
The message
is not translated at all through this step.
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.
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.
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 USEputAscii() 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.