This section describes the specific properties of intra-group queuing.
Refer to WebSphere MQ Script (MQSC) Command Reference, WebSphere MQ Application Programming Reference and WebSphere MQ for z/OS System Setup Guide for details of queue name resolution when intra-group queuing is used.
If the attributes of an object are found to have changed after the object is opened, the queue manager invalidates the object handle with MQRC_OBJECT_CHANGED on its next use.
Intra-group queuing introduces the following new rules for object handle invalidation :
In the event that the IGQ agent terminates abnormally, message CSQM067E is issued and the IGQ agent performs self recovery.
In the event that the IGQ agent encounters a problem accessing the
SYSTEM.QSG.TRANSMIT.QUEUE (because it is not defined, for
example, or is defined with incorrect attributes, or is inhibited for Gets, or
for some other reason), the IGQ agent goes into the state of retry. The
IGQ agent observes short and long retry counts and intervals. The
values for these counts and intervals, which cannot be changed, are as
follows:
| Constant | Value |
| Short retry count | 10 |
| Short retry interval | 60 secs = 1 min |
| Long retry count | 999,999,999 |
| Long retry interval | 1200 secs = 20 min |
If there is a failure of a queue manager in a queue-sharing group while the IGQ agent is dealing with uncommitted messages on a shared queue or queues, the IGQ agent ends, and shared queue peer recovery takes place for the failing queue manager. Because shared queue peer recovery is an asynchronous activity, this leaves the possibility for the failing queue manager, and also the IGQ agent for that queue manager, to restart before shared queue peer recovery is complete. This in turn leaves the possibility for any committed messages to be processed ahead of and out of sequence with the messages still being recovered. To ensure that messages are not processed out of sequence, the IGQ agent serializes access to shared queues by issuing the MQCONNX API call.
An attempt, by the IGQ agent to serialize access to shared queues while peer recovery is still in progress might fail. An error message is issued and the IGQ agent is put into retry state. When queue manager peer recovery is complete, for example at the time of the next retry, the IGQ agent can start.