After a dynamic queue has been deleted, any call (other than MQCLOSE) that attempts to reference the queue using a previously acquired Hobj handle fails with reason code MQRC_Q_DELETED.
Although applications cannot access a deleted queue, the queue is not removed from the system, and associated resources are not freed, until such time as all handles that reference the queue have been closed, and all units of work that affect the queue have been either committed or backed out.
On z/OS, a queue that has been logically deleted but not yet removed from the system prevents the creation of a new queue with the same name as the deleted queue; the MQOPEN call fails with reason code MQRC_NAME_IN_USE in this case. Also, such a queue can still be displayed using MQSC commands, even though it cannot be accessed by applications.
This check is not performed if:
If there are uncommitted units of work that affect the queue, the queue and its messages are still deleted, but the units of work do not fail. However, as described above, the resources associated with the units of work are not freed until each of the units of work has been either committed or backed out.
If a failure occurs closing one of the queues, the queue manager continues processing and attempts to close the remaining queues in the distribution list. The CompCode and Reason parameters of the call are set to return information describing the failure. It is possible for the completion code to be MQCC_FAILED, even though most of the queues were closed successfully. The queue that encountered the error is not identified.
If there is a failure on more than one queue, it is not defined which failure is reported in the CompCode and Reason parameters.
Only applications running in compatibility mode can be connected implicitly; other applications must issue the MQCONN or MQCONNX call to connect to the queue manager explicitly.
Notices |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
closuse |