Outbound messages

 

Outbound messages from the bridge have one of three structures, depending on whether an error occurred. Although only a single vector is shown in each of these examples, messages can contain several concatenated vectors, except when an error occurs.

• This structure is used when bridge processing concludes normally, no errors were detected, and no data is to be returned to the bridge application:

   -------------------------------
  | MQMD | MQCIH | BRMQ structure |
   -------------------------------
  

  Even if an application abends, this is still regarded as normal completion by the bridge. The abend code issued by the application is given in the MQCIH.

• This structure is used when bridge processing concludes normally, no errors were detected, and data is to be returned to the bridge application:

   --------------------------------------
  | MQMD | MQCIH | BRMQ structure | data |
   --------------------------------------
  

  BRMQ structure represents any of the architected outbound reply or request vector structures.

• This structure is used when bridge processing concludes abnormally, an error having been detected by the bridge monitor:

   ------------------------------
  | 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, to ensure 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.

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. Only a single vector is shown associated with any message. In practice, a message might contain several vectors concatenated:

   • Inbound messages can contain several RECEIVE MAP vectors in anticipation of future RECEIVE MAP requests from the CICS transaction. The application needs to know the flow of control in the transaction in order to construct the message.

   • Outbound messages can contain several vectors, for example as a result of successive EXEC CICS SEND MAP commands being issued by a transaction. The CICS transaction does not control whether the outbound message contains a single vector or multiple vectors.

     If the transaction issues a command that generates a request vector, the request vector is always the last one in the message.

 

Parent topic:

CICS 3270 bridge message structure

fg15560_