Controlling the IMS bridge

Use this topic to understand the IMS commands that we can use to control the IMS bridge.

There are no IBM MQ commands to control the IBM MQ-IMS bridge. However, we can stop messages being delivered to IMS in the following ways:

  • For non-shared queues, by using the ALTER QLOCAL(xxx) GET(DISABLED) command for all bridge queues.
  • For clustered queues, by using the SUSPEND QMGR CLUSTER(xxx) command. This is effective only when another queue manager is also hosting the clustered bridge queue.
  • For clustered queues, by using the SUSPEND QMGR FACILITY(IMSBRIDGE) command. No further messages are sent to IMS, but the responses for any outstanding transactions are received from IMS.

    To start sending messages to IMS again, issue the RESUME QMGR FACILITY(IMSBRIDGE) command.

We can also use the MQSC command DISPLAY SYSTEM to display whether the bridge is suspended.

See MQSC commands for details of these commands.

For further information see:


Starting and stopping the IMS bridge

Start the IBM MQ bridge by starting OTMA. Either use the IMS command: 
/START OTMA

or start it automatically by specifying OTMA=YES in the IMS system parameters. If OTMA is already started, the bridge starts automatically when queue manager startup has completed. An IBM MQ event message is produced when OTMA is started.

Use the IMS command: 
/STOP OTMA

to stop OTMA communication. When this command is issued, an IBM MQ event message is produced.


Controlling IMS connections

IMS provides these operator commands to control and monitor the connection to IBM MQ:

    /DEQUEUE TMEMBER tmember TPIPE tpipe
    Removes messages from a Tpipe. Specify PURGE to remove all messages or PURGE1 to remove the first message only.

    /DISPLAY OTMA
    Displays summary information about the OTMA server and clients, and client status.

    /DISPLAY TMEMBER name
    Displays information about an OTMA client.

    /DISPLAY TRACE TMEMBER name
    Displays information about what is being traced.

    /SECURE OTMA
    Sets security options.

    /START OTMA
    Enables communications through OTMA.

    /START TMEMBER tmember TPIPE tpipe
    Starts the named Tpipe.

    /STOP OTMA
    Stops communications through OTMA.

    /STOP TMEMBER tmember TPIPE tpipe
    Stops the named Tpipe.

    /TRACE
    Controls the IMS trace.

For more information about these commands, see the IMS/ESA® Operators Reference manual for the level of IMS that you are using.

IMS command responses are sent to the terminal from which the command was issued. Authorization to issue IMS commands is based on IMS security.


Controlling bridge queues

To stop communicating with the queue manager with XCF member name tmember through the bridge, issue the following IMS command: 
/STOP TMEMBER tmember TPIPE ALL
To resume communication, issue the following IMS command: 
/START TMEMBER tmember TPIPE ALL

The Tpipes for a queue can be displayed using the MQ DISPLAY QUEUE command.

To stop communication with the queue manager on a single Tpipe, issue the following IMS command: 
/STOP TMEMBER tmember TPIPE tpipe
One or two Tpipes are created for each active bridge queue, so issuing this command stops communication with the IBM MQ queue. To resume communication, use the following IMS command : 
/START TMEMBER tmember TPIPE tpipe

Alternatively, we can alter the attributes of the IBM MQ queue to make it get inhibited.


Resynchronizing the IMS bridge

The IMS bridge is automatically restarted whenever the queue manager, IMS, or OTMA are restarted.

The first task undertaken by the IMS bridge is to resynchronize with IMS. This involves IBM MQ and IMS checking sequence numbers on every synchronized Tpipe. A synchronized Tpipe is used when persistent messages are sent to IMS from an IBM MQ - IMS bridge queue using commit mode zero (commit-then-send).

If the bridge cannot resynchronize with IMS, the IMS sense code is returned in message CSQ2023E and the connection to OTMA is stopped. If the bridge cannot resynchronize with an individual IMS Tpipe, the IMS sense code is returned in message CSQ2025E and the Tpipe is stopped. If a Tpipe has been cold started, the recoverable sequence numbers are automatically reset to 1.

If the bridge discovers mismatched sequence numbers when resynchronizing with a Tpipe, message CSQ2020E is issued. Use the IBM MQ command RESET TPIPE to initiate resynchronization with the IMS Tpipe. You need to provide the XCF group and member name, and the name of the Tpipe; this information is provided by the message.

We can also specify:

  • A new recoverable sequence number to be set in the Tpipe for messages sent by IBM MQ, and to be set as the partner's receive sequence number. If we do not specify this, the partner's receive sequence number is set to the current IBM MQ send sequence number.
  • A new recoverable sequence number to be set in the Tpipe for messages received by IBM MQ, and to be set as the partner's send sequence number. If we do not specify this, the partner's send sequence number is set to the current IBM MQ receive sequence number.

If there is an unresolved unit of recovery associated with the Tpipe, this is also notified in the message. Use the IBM MQ command RESET TPIPE to specify whether to commit the unit of recovery, or back it out. If you commit the unit of recovery, the batch of messages has already been sent to IMS, and is deleted from the bridge queue. If you back the unit of recovery out, the messages are returned to the bridge queue, to be later sent to IMS.

Commit mode 1 (send-then-commit) Tpipes are not synchronized.

    Considerations for Commit mode 1 transactions

    In IMS, commit mode 1 (CM1) transactions send their output replies before sync point.

    A CM1 transaction might not be able to send its reply, for example because:

    • The Tpipe on which the reply is to be sent is stopped
    • OTMA is stopped
    • The OTMA client (that is, the queue manager) has gone away
    • The reply-to queue and dead-letter queue are unavailable

    For these reasons, the IMS application sending the message pseudo-abends with code U0119. The IMS transaction and program are not stopped in this case.

    These reasons often prevent messages being sent into IMS, as well as replies being delivered from IMS. A U0119 abend can occur if:

    • The Tpipe, OTMA, or the queue manager is stopped while the message is in IMS
    • IMS replies on a different Tpipe to the incoming message, and that Tpipe is stopped
    • IMS replies to a different OTMA client, and that client is unavailable.

    Whenever a U0119 abend occurs, both the incoming message to IMS and the reply messages to IBM MQ are lost. If the output of a CM0 transaction cannot be delivered for any of these reasons, it is queued on the Tpipe within IMS.


Working with tpipe names

Many of the commands used to control the IBM MQ - IMS bridge require the tpipe name. Use this topic to understand how we can find further details of the tpipe name.

You need tpipe names for many of the commands that control the IBM MQ - IMS bridge. We can get the tpipe names from DISPLAY QUEUE command and note the following points:

  • tpipe names are assigned when a local queue is defined
  • a local queue is given two tpipe names, one for sync and one for non-sync
  • tpipe names will not be known to IMS until after some communication between IMS and IBM MQ specific to that particular local queue takes place
  • For a tpipe to be available for use by the IBM MQ - IMS bridge its associated queue must be assigned to a Storage Class that has the correct XCF group and member name fields completed


Delete messages from IMS

A message that is destined for IBM MQ through the IMS bridge can be deleted if the Tmember/Tpipe is stopped. To delete one message for the queue manager with XCF member name tmember, issue the following IMS command: 
/DEQUEUE TMEMBER tmember TPIPE tpipe PURGE1
To delete all the messages on the Tpipe, issue the following IMS command: 
/DEQUEUE TMEMBER tmember TPIPE tpipe PURGE


Delete tpipes

We cannot delete IMS tpipes yourself. They are deleted by IMS at the following times:

  • Synchronized tpipes are deleted when IMS is cold started.
  • Non-synchronized tpipes are deleted when IMS is restarted.


IMS Transaction Expiration

An expiration time is associated with a transaction; any IBM MQ message can have an expiration time associated with it. The expiration interval is passed from the application, to IBM MQ, using the MQMD.Expiry field. The time is the duration of a message before it expires, expressed as a value in tenths of a second. An attempt to perform the MQGET of a message, later than it has expired, results in the message being removed from the queue and expiry processing performed. The expiration time decreases as a message flows between queue managers on an IBM MQ network. When an IMS message is passed across the IMS bridge to OTMA, the remaining message expiry time is passed to OTMA as a transaction expiration time.

If a transaction has an expiration time specified, OTMA expires the input transactions in three different places in IMS:

  • input message receiving from XCF
  • input message enqueuing time
  • application GU time
No expiration is performed after the GU time. The transaction EXPRTIME can be provided by:

  • IMS transaction definition
  • IMS OTMA message header
  • IMS DFSINSX0 user exit
  • IMS CREATE or UPDATE TRAN commands
IMS indicates that it has expired a transaction by abending a transaction with 0243, and issuing a message. The message issued is either DFS555I in the non-shared-queues environment, or DFS2224I in the shared-queues environment.