Design Considerations for MQ Application Programs

This article describes information to consider when designing IDMS MQ application programs for message queueing:
This article describes information to consider when designing IDMS MQ application programs for message queueing:
Automatic MQ Connect and Disconnect
Issuing an MQCONN to connect to IBM MQ from an IDMS MQ application program is optional. If an MQCONN has not been issued and a connection does not already exist, the connection is done automatically on the MQOPEN.  If MQCONN is issued, the queue manager name is ignored. The connection, when made, is always made to the queue manager specified for the CV.
Issuing an MQDISC to disconnect is also optional. MQDISC does not disconnect the connection to the IBM MQ queue manager. The connection remains until the MQ Adapter connection to IBM MQ is terminated. 
For more information about MQCONN and MQDISC
see the following 
MQ Sessions 
section and see
the MQI Function Descriptions.
MQ Sessions
An IDMS MQ session is an internal structure that is used to track open MQ objects and uncommitted units-of-work for a DC task and to reserve a subtask during the session. A session is allocated when an application issues MQCONN or on the first MQOPEN. The session is released when the DC task ends or when MQDISC is issued. If the session is created on the first MQOPEN, it is released on the last MQCLOSE or when uncommitted work is resolved (committed or backed out).
 A session can also be created for some MQ functions such as MQPUT1 and MQSTAT and can be released when the call ends. When a session ends, open queues are closed and its subtask is released. When the session ends normally, uncommitted work is committed. When the session ends abnormally, uncommitted work it is backed out.   
A subtask is not connected to MQ until the first session reserves it and issues an MQCONN, MQOPEN, MQPUT1, or MQSTAT function call. The subtask remains connected to MQ until the IDMS MQ connection is disabled. If already connected, new sessions use the existing subtask connection. 
Trigger Monitor 
After the MQ Trigger Monitor retrieves a trigger message from an initiation queue, a DC task starts and invokes a DC program. The program passes the address of the trigger message data. Optionally, the program can get access to the data for possible use in the program. For more information, see Trigger Message Passed to an Invoked Program
Quiesce Processing
When the MQ connection is disabled with a DCMT V MQ DISABLE command and there are active sessions, the connection goes into a quiesce state. Any MQ function which results in the creation of a new session fails with a MQRC_Q_MGR_QUIESCING reason code. Existing sessions are allowed to complete normally. When the last session ends, the IDMS MQ connection is disabled. The connection remains disabled until enabled with a DCMT V MQ ENABLE command or the CV is restarted.
In a quiesce state and there is an active session, MQ functions MQOPEN, MQGET, MQPUT, and MQPUT1 fail with reason code MQRC_Q_MGR_QUIESCING if the MQxxx_FAIL_IF_QUIESCING option is set, otherwise the functions are passed through to MQ normally.