Overview for MQCIH
The MQCIH structure describes the header information for a message sent to CICS across the CICS bridge. For any IBM MQ supported platform we can create and transmit a message that includes the MQCIH structure, but only an IBM MQ for z/OS queue manager can use the CICS bridge. Therefore, for the message to get to CICS from a non-z/OS queue manager, your queue manager network must include at least one z/OS queue manager through which the message can be routed.
Availability: The MQCIH structure is available on the following platforms:- AIX
- Linux
- Windows
- z/OS
and for IBM MQ MQI clients connected to these systems.
Purpose: The MQCIH structure describes the information that can be present at the start of a message sent to the CICS bridge through IBM MQ for z/OS.
Format name: MQFMT_CICS.
Version: The current version of MQCIH is MQCIH_VERSION_2. Fields that exist only in the more-recent version of the structure are identified as such in the descriptions that follow.
The header, COPY, and INCLUDE files provided for the supported programming languages contain the most-recent version of MQCIH, with the initial value of the Version field set to MQCIH_VERSION_2.
Character set and encoding: Special conditions apply to the character set and encoding used for the MQCIH structure and application message data:- Applications that connect to the queue manager that owns the CICS bridge queue must provide an MQCIH structure that is in the character set and encoding of the queue manager. This is because data conversion of the MQCIH structure is not performed in this case.
- Applications that connect to other queue managers can provide an MQCIH structure that is in any of the supported character sets and encodings; the receiving message channel agent connected to the queue manager that owns the CICS bridge queue converts the MQCIH structure.
- The application message data following the MQCIH structure must be in the same character set and encoding as the MQCIH structure. We cannot use the CodedCharSetId and Encoding fields in the MQCIH structure to specify the character set and encoding of the application message data.
We must provide a data-conversion exit to convert the application message data if the data is not one of the built-in formats supported by the queue manager.
Usage: If the application requires values that are the same as the initial values shown in Table 1, and the bridge is running with AUTH=LOCAL or AUTH=IDENTIFY, we can omit the MQCIH structure from the message. In all other cases, the structure must be present.
The bridge accepts either a version-1 or a version-2 MQCIH structure, but for 3270 transactions, we must use a version-2 structure.
The application must ensure that fields documented as request fields have appropriate values in the message sent to the bridge; these fields are input to the bridge.
Fields documented as response fields are set by the CICS bridge in the reply message that the bridge sends to the application. Error information is returned in the ReturnCode, Function, CompCode, Reason, and AbendCode fields, but not all of them are set in all cases. Table 1 shows which fields are set for different values of ReturnCode.ReturnCode | Function | CompCode | Reason | AbendCode |
---|---|---|---|---|
MQCRC_OK | - | - | - | - |
MQCRC_BRIDGE_ERROR | - | - | MQFB_CICS_* | - |
MQCRC_MQ_API_ERROR MQCRC_BRIDGE_TIMEOUT | MQ call name | MQ CompCode | MQ Reason | - |
MQCRC_CICS_EXEC_ERROR MQCRC_SECURITY_ERROR MQCRC_PROGRAM_NOT_AVAILABLE MQCRC_TRANSID_NOT_AVAILABLE | CICS EIBFN | CICS EIBRESP | CICS EIBRESP2 | - |
MQCRC_BRIDGE_ABEND MQCRC_APPLICATION_ABEND | - | - | - | CICS ABCODE |