Controlling the IMS bridge
Use this topic to understand the IMS commands that you can use to control the IMS bridge.
- 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.
You can also use the MQSC command DISPLAY SYSTEM to display whether the bridge is suspended.
See MQSC commands for details of these commands.
Starting and stopping the IMS bridge
/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.
/STOP OTMA
to stop OTMA communication. When this command is issued, an IBM MQ event message is produced.
Controlling IMS connections
- /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
/STOP TMEMBER tmember TPIPE ALL
/START TMEMBER tmember TPIPE ALL
The Tpipes for a queue can be displayed using the MQ DISPLAY QUEUE command.
/STOP TMEMBER tmember TPIPE tpipe
/START TMEMBER tmember TPIPE tpipe
Alternatively, you 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.
- 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 you 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 you 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 you can find further details of the tpipe name.
You need tpipe names for many of the commands that control the IBM MQ - IMS bridge. You 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
Deleting messages from IMS
/DEQUEUE TMEMBER tmember TPIPE tpipe PURGE1
/DEQUEUE TMEMBER tmember TPIPE tpipe PURGE
Deleting tpipes
- 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.
- input message receiving from XCF
- input message enqueuing time
- application GU time
- IMS transaction definition
- IMS OTMA message header
- IMS DFSINSX0 user exit
- IMS
CREATE
orUPDATE TRAN
commands