Browse Prior Art Database

Alias message formats

IP.com Disclosure Number: IPCOM000014210D
Original Publication Date: 2000-Oct-01
Included in the Prior Art Database: 2003-Jun-19
Document File: 2 page(s) / 41K

Publishing Venue

IBM

Abstract

In a message processing system, such as MQSeries*, the messages are accompanied by a structure known as the Message Descriptor (MsgDesc). This has many fields, describing various attributes of the message, for example the time of creation and the codepage of the message. One of the fields of the MsgDesc, known as the Format field, describes the format of the message. Applications have found this field useful, for example as a way of indicating how the message should be processed (e.g. if the format were "xml" it could be passed to an xml parser). However, the information in this field is sometimes used by the message processor (queue manager in MQSeries), so there are constraints on the values applications should set in it. When messages are sent between platforms it may be necessary to convert the codepage of characters in the message to the one used on the receiving platform, and/or it may be necessary to convert the encoding of numbers in the message to the one used on the receiving platform (e.g. big or little endian). The application may opt for this conversion to be done by the message processor, in which case the message processor needs to know which bytes in the message are numbers and which are characters, so that the correct type of conversion may be performed on them. It is the MsgDesc Format field which provides this information about the message. The value in the Format field may be thought of as a name for the structure of the message. The message processor will be able to handle a certain number of formats, known as the built-in formats. These are likely to include a pure string of characters, or an array of integers, or other commonly used structures. If the message processor is asked to convert a message, and its format is one of the built in formats, then it can perform the conversion. If the format of the message is something else the message processor will normally not be able to convert the message, and the application requesting the conversion will be told that the message cannot be converted into the character codepage or number encoding requested by the application. To allow formats other than the built-in formats to be handled the application may supply a conversion exit to do this, which the message processor will invoke if the format is not one of the built-in formats. Hence the value put in the Format field must be limited to the names of built-in or exit-supplied formats. This means that the application cannot use the Format field to distinguish between different kinds of pure string, for example "xml" or "html", unless it provides a conversion exit for each of these format names. It is also a nuisance, and may have performance implications, to have to provide a conversion exit for a format which is in fact to be treated (as far as conversion is concerned) identically to one of the built-in formats.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

Alias message formats

In a message processing system, such as MQSeries*, the messages are accompanied by a structure known as the Message Descriptor (MsgDesc). This has many fields, describing various attributes of the message, for example the time of creation and the codepage of the message. One of the fields of the MsgDesc, known as the Format field, describes the format of the message. Applications have found this field useful, for example as a way of indicating how the message should be processed (e.g. if the format were "xml" it could be passed to an xml parser). However, the information in this field is sometimes used by the message processor (queue manager in MQSeries), so there are constraints on the values applications should set in it.

     When messages are sent between platforms it may be necessary to convert the codepage of characters in the message to the one used on the receiving platform, and/or it may be necessary to convert the encoding of numbers in the message to the one used on the receiving platform (e.g. big or little endian). The application may opt for this conversion to be done by the message processor, in which case the message processor needs to know which bytes in the message are numbers and which are characters, so that the correct type of conversion may be performed on them. It is the MsgDesc Format field which provides this information about the message. The value in the Format field may be thought of as a name for the structure of the message.

     The message processor will be able to handle a certain number of formats, known as the built-in formats. These are likely to include a pure string of characters, or an array of integers, or other commonly used structures. If the message processor is asked to convert a message, and its format is one of the built in formats, then it can perform the conversion. If the format of the message is something else the message processor will normally not be able to convert the message, and the application requesting the conversion will be told that the message cannot be converted into the character codepage or number encoding requested by the application. To allow formats other than the built-in formats to be handled the application may supply a conversion exit to do this, which the message processor will invoke if the format is not one of the built-in formats. Hence the value put in the Format field must be limited to the names of built-in or exit-supplied formats.

     This means that the application cannot use the Format field to distingu...