CICS DPL bridge message structure

 

These examples show the different structures that we can use for messages that run DPL programs through the bridge.

If a bridge task running a DPL program ends abnormally, it returns a message to the reply queue with the following structure, whether or not the inbound message preceding the failure contains an MQCIH:

┌──────┬───────┬───────────────┐
│ MQMD │ MQCIH │ CSQC* message │
└──────┴───────┴───────────────┘
CSQC* message represents an error message that indicates the error type. The value of field MQCIH.Format is set to MQFMT_STRING, so that the message can be properly converted if the final destination uses a different CCSID and encoding. The MQCIH also contains other fields that we can use to diagnose the problem.

Optionally, additional headers with format names beginning MQH, and containing standard link fields, can precede the MQCIH header. Such headers are returned unmodified in the output message because the bridge makes no use of data within the headers

  1. The MQMD is shown in the examples to help you to visualize the overall structure of the message. This is the structure that you see if you use the general queue browser utility of WebSphere MQ SupportPac MA10 "MQSeries for MVS/ESA™ - ISPF utilities".

  2. If you want to send only a program name, and no COMMAREA data, to the bridge, the program name must be 8 characters long. It must not be a name that is padded to the right with spaces, or the bridge reports a COMMAREA negative length error.

  3. If you want to send COMMAREA data, pad the program name with spaces to the right, to give a total length of eight characters.

  4. We can include control data in the message to specify unit of work management, and to provide data for security checking, when you include a WebSphere MQ CICS information header (CIH) in the message.

 

Parent topic:

Using CICS DPL programs with the bridge


fg15440_