How the WebSphere MQ-IMS bridge deals with messages

 

When you use the WebSphere MQ-IMS bridge to send messages to an IMS™ application, we need to construct your messages in a special format. You must also put your messages on WebSphere MQ queues that have been defined with a storage class that specifies the XCF group and member name of the target IMS system. These are known as MQ-IMS bridge queues, or simply bridge queues.

A user does not need to sign on to IMS before sending messages to an IMS application. The user ID in the UserIdentifier field of the MQMD structure is used for security checking. The level of checking is determined when WebSphere MQ connects to IMS, and is described in the security section of the WebSphere MQ for z/OS System Setup Guide. This enables a pseudo signon to be implemented.

The WebSphere MQ-IMS bridge accepts the following types of message:

• Messages containing IMS transaction data and an MQIIH structure (described in the Application Programming Reference):

  MQIIH LLZZ<trancode><data>[LLZZ<data>][LLZZ<data>]

  1. The square brackets, [ ], represent optional multi-segments.

  2. Set the Format field of the MQMD structure to MQFMT_IMS to use the MQIIH structure.

• Messages containing IMS transaction data but no MQIIH structure:

  LLZZ<trancode><data>  \
  [LLZZ<data>][LLZZ<data>]

WebSphere MQ validates the message data to ensure that the sum of the LL bytes plus the length of the MQIIH (if it is present) is equal to the message length.

When the WebSphere MQ-IMS bridge gets messages from the bridge queues, it processes them as follows:

• If the message contains an MQIIH structure, the bridge verifies the MQIIH (see the Application Programming Reference), builds the OTMA headers, and sends the message to IMS. The transaction code is specified in the input message. If this is an LTERM, IMS replies with a DFS1288E message. If the transaction code represents a command, IMS executes the command; otherwise the message is queued in IMS for the transaction.

• If the message contains IMS transaction data, but no MQIIH structure, the IMS bridge makes the following assumptions:

  • The transaction code is in bytes 5 through 12 of the user data

  • The transaction is in nonconversational mode

  • The transaction is in commit mode 0 (commit-then-send)

  • The Format in the MQMD is used as the MFSMapName (on input)

  • The security mode is MQISS_CHECK

  The reply message is also built without an MQIIH structure, taking the Format for the MQMD from the MFSMapName of the IMS output.

The WebSphere MQ-IMS bridge uses one or two Tpipes for each WebSphere MQ queue:

• A synchronized Tpipe is used for all messages using Commit mode 0 (COMMIT_THEN_SEND) (these show with SYN in the status field of the IMS /DIS TMEMBER client TPIPE xxxx command)

• A non-synchronized Tpipe is used for all messages using Commit mode 1 (SEND_THEN_COMMIT)

The Tpipes are created by WebSphere MQ when they are first used. A non-synchronized Tpipe exists until IMS is restarted. Synchronized Tpipes exist until IMS is cold started. We cannot delete these Tpipes yourself.

• Mapping WebSphere MQ messages to IMS transaction types
  

• If the message cannot be put to the IMS queue
  

• IMS bridge feedback codes
  

• The MQMD fields in messages from the IMS bridge
  

• The MQIIH fields in messages from the IMS bridge
  

• Reply messages from IMS
  

• Using alternate response PCBs in IMS transactions
  

• Sending unsolicited messages from IMS
  

• Message segmentation
  

• Data conversion
  

 

Parent topic:

Writing WebSphere MQ-IMS bridge applications

fg15870_