When converting a built-in format, the queue manager follows the processing conventions described below. User-written exits should also follow these conventions, although this is not enforced by the queue manager. The built-in formats converted by the queue manager are:
This can occur, for example, if a 4-byte integer or a DBCS character straddles the end of the buffer. The incomplete element of information is not converted, and those bytes in the returned message do not contain valid information. This can also occur if a message that was truncated before conversion shrinks during conversion.
If the number of valid bytes returned is less than the length of the buffer, the unused bytes at the end of the buffer are set to nulls.
For the string-list structure MQCFSL, the strings in the list might expand or contract by different amounts. If this happens, the queue manager pads the shorter strings with blanks to make them the same length as the longest string after conversion.
The two exceptions are the MQCIH and MQIIH structures, where the values in the CodedCharSetId and Encoding fields in those structures are not significant. For those structures, the data following the structure is in the same character set and encoding as the MQCIH or MQIIH structure itself.
For example, if the Encoding field in the message specifies an unsupported float encoding, but the message contains only integer data, or contains floating-point data that does not require conversion (because the source and target float encodings are identical), the error might not be diagnosed.
If the error is diagnosed, the message is returned unconverted, with completion code MQCC_WARNING and one of the MQRC_SOURCE_*_ERROR or MQRC_TARGET_*_ERROR reason codes (as appropriate); the CodedCharSetId and Encoding fields in the MsgDesc parameter are set to the values in the control information in the message.
If the error is not diagnosed and the conversion completes successfully, the values returned in the CodedCharSetId and Encoding fields in the MsgDesc parameter are those specified by the application issuing the MQGET call.
The Reason parameter is set to a code that indicates why the conversion could not be carried out, unless the message also had to be truncated; reason codes related to truncation take precedence over reason codes related to conversion. (To determine if a truncated message was converted, check the values returned in the CodedCharSetId and Encoding fields in the MsgDesc parameter.)
When an error is diagnosed, either a specific reason code is returned, or the general reason code MQRC_NOT_CONVERTED. The reason code returned depends on the diagnostic capabilities of the underlying data-conversion service.
The following processing is specific to the built-in formats; it does not apply to user-defined formats:
The Unicode character set UCS-2 is an example of a character set that does not have SBCS characters for the characters that are valid in queue names.
When processing messages such as a truncated MQFMT_ADMIN message, ensure that the application does not attempt to access data beyond the end of the data returned.
The queue manager converts the MQDLH structure first, as necessary. If conversion is successful, or the MQDLH structure does not require conversion, the queue manager checks the CodedCharSetId and Encoding fields in the MQDLH structure to see if conversion of the application message data is required. If conversion is required, the queue manager invokes the user-written exit with the name given by the Format field in the MQDLH structure, or performs the conversion itself (if Format is the name of a built-in format).
If the MQGET call returns a completion code of MQCC_WARNING, and the reason code is one of those indicating that conversion was not successful, one of the following applies:
The application can examine the values returned in the CodedCharSetId and Encoding fields in the MsgDesc parameter, and those in the MQDLH structure, in order to determine which of the above applies.
The MQXQH structure must be in the character set and encoding of the queue manager. The format, character set, and encoding of the data following the MQXQH structure are given by the Format, CodedCharSetId, and Encoding fields in the MQMD structure contained within the MQXQH. For each subsequent MQ header structure present, the Format, CodedCharSetId, and Encoding fields in the structure describe the data that follows that structure; that data is either another MQ header structure, or the application message data.
If the MQGMO_CONVERT option is specified for an MQFMT_XMIT_Q_HEADER message, the application message data and certain of the MQ header structures are converted, but the data in the MQXQH structure is not. On return from the MQGET call, therefore:
The effect of this is that an application that repeatedly gets messages from a transmission queue with the MQGMO_CONVERT option specified must reset the CodedCharSetId and Encoding fields in the MsgDesc parameter to the values required for the application message data, prior to each MQGET call.
If the message is a distribution-list message, the MQXQH structure is followed by an MQDH structure (plus its arrays of MQOR and MQPMR records), which in turn might be followed by zero or more further MQ header structures and zero or more bytes of application message data. Like the MQXQH structure, the MQDH structure must be in the character set and encoding of the queue manager, and it is not converted on the MQGET call, even if the MQGMO_CONVERT option is specified.
The processing of the MQXQH and MQDH structures described above is primarily intended for use by message channel agents when they get messages from transmission queues.
Notices |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
convc |