How the IMS bridge deals with messages

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

We 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.

• 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.

• 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. We cannot delete these Tpipes yourself.

• Mapping IBM MQ messages to IMS transaction types
  A table describing the mapping of IBM MQ messages to IMS transaction types.
• If the message cannot be put to the IMS queue
  Learn about actions to take if the message cannot be put to the IMS queue.
• IMS bridge feedback codes
  IMS sense codes are typically output in hexadecimal format in IBM MQ console messages such as CSQ2001I (for example, sense code 0x001F). IBM MQ feedback codes as seen in the dead-letter header of messages put to the dead-letter queue are decimal numbers.
• The MQMD fields in messages from the IMS bridge
  Learn about the MQMD fields in messages from the IMS bridge.
• The MQIIH fields in messages from the IMS bridge
  Learn about the MQIIH fields in messages from the IMS bridge.
• Reply messages from IMS
  When an IMS transaction ISRTs to its IOPCB, the message is routed back to the originating LTERM or TPIPE.
• Use alternate response PCBs in IMS transactions
  When an IMS transaction uses alternate response PCBs (ISRTs to the ALTPCB, or issues a CHNG call to a modifiable PCB), the pre-routing exit (DFSYPRX0) is invoked to determine if the message should be rerouted.
• Send unsolicited messages from IMS
  To send messages from IMS to an IBM MQ queue, we need to invoke an IMS transaction that ISRTs to an ALTPCB.
• Message segmentation
  We can define IMS transactions as expecting single- or multi-segment input.
• Data conversion
  The data conversion is performed by either the distributed queuing facility (which may call any necessary exits) or by the intra group queuing agent (which does not support the use of exits) when it puts a message to a destination queue that has XCF information defined for its storage class. The data conversion does not occur when a message is delivered to a queue by publish/subscribe.

Parent topic: Writing IMS bridge applications

Related concepts

• Writing IMS transaction programs through IBM MQ