How the IMS bridge deals with messages

When you use the IBM® MQ - IMS bridge to send messages to an IMS application, you need to construct your messages in a special format.

You must also put your messages on IBM 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.

The IBM MQ-IMS bridge requires exclusive input access (MQOO_INPUT_EXCLUSIVE) to the bridge queue if it is defined with QSGDISP(QMGR), or if it is defined with QSGDISP(SHARED) together with the NOSHARE option.

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 IBM MQ connects to IMS, and is described in Application access control for the IMS bridge. This enables a pseudo signon to be implemented.

The IBM MQ - IMS bridge accepts the following types of message:
  • Messages containing IMS transaction data and an MQIIH structure (described in MQIIH ): 
    
MQIIH LLZZ<trancode><data>[LLZZ<data>][LLZZ<data>]
    Note:
    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>]

IBM 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 IBM 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 MQIIH ), 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 IBM MQ - IMS bridge uses one or two Tpipes for each IBM 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 IBM MQ when they are first used. A non-synchronized Tpipe exists until IMS is restarted. Synchronized Tpipes exist until IMS is cold started. You cannot delete these Tpipes yourself.

See the following topics for more information about how the IBM MQ - IMS bridge deals with messages: