Generation of MQRFH2 headers

If IBM® MQ converts message properties to their MQRFH2 representation, it must add the MQRFH2 to the message. It adds the MQRFH2 either as a separate header, or merges it with an existing header.

Generation of new MQRFH2 headers by IBM MQ might disrupt existing headers in a message. Applications that parse a message buffer for headers must be aware that the number and position of headers in a buffer might change in some circumstances. IBM MQ attempts to minimize the impact of adding properties to a message by merging message properties into an existing MQRFH2 header, where it can. It also attempts to minimize the impact by inserting a generated MQRFH2 into a fixed position relative to other headers in the message buffer.

A generated MQRFH2 header is placed following the MQMD, and any number of MQXQH, MQRFH, and MQDLH headers, whatever order they are in. The generated MQRFH2 header is placed immediately before the first header that is not an MQMD, MQXQH, MQDLH, or MQRFH header.

On z/OS® systems, the generated MQRFH2 header is created in the application's CCSID. This is defined as follows:

• For batch LE applications using the DLL interface, the CCSID is the CODESET associated with the current locale at the time MQCONN is issued (default value is 1047).
• For batch LE applications bound with one of the batch MQ stubs, the CCSID is the CODESET associated with the current locale at the time of the first MQI call issued after MQCONN (default value is 1047).
• For batch non-LE applications running on a USS thread, the CCSID is the value of THLICCSID at the time of the first MQI call issued after MQCONN (default value is 1047).
• For other batch applications, the CCSID is the CCSID of the queue manager.

For LE applications, the locale can be changed using the setlocale() / CEESETL LE callable service. For non-LE applications running on USS threads, the value of THLICCSID can be changed using USS mapping macro BPXYTHLI.