{"id":6488,"date":"2017-02-11T18:35:36","date_gmt":"2017-02-11T10:35:36","guid":{"rendered":"http:\/\/rmohan.com\/?p=6488"},"modified":"2017-02-11T18:35:36","modified_gmt":"2017-02-11T10:35:36","slug":"ipprocs-or-opprocs-greater-than-0-in-a-queue-prevents-normal-termination-of-queue-manager-by-endmqm-qmgrname-need-to-use-endmqm-i-qmgrname","status":"publish","type":"post","link":"https:\/\/mohan.sg\/?p=6488","title":{"rendered":"IPPROCS or OPPROCS greater than 0 in a queue prevents normal termination of queue manager by “endmqm QmgrName” (Need to use: endmqm -i QmgrName)"},"content":{"rendered":"
\n

Problem(Abstract)<\/h2>\n

You notice that when the WebSphere MQ (WMQ) queue attributes of IPPROCS or OPPROCS are greater than 0, and try to end the queue manager by issuing “endmqm QmgrName”, then the queue manager goes into “quiescing” but it does not fully terminate.<\/p>\n

Is there a way to speed up the shutdown of the queue manager?<\/p>\n

Resolving the problem<\/h2>\n
\n

If “endmqm QMgrName” does not effectively end the queue manager, you can try to speed up the shutdown process by adding the flag -i such as:
\nendmqm -i QMgrName<\/i><\/b> <\/b><\/p>\n

Background:<\/u><\/b><\/p>\n

The following page has more information about the IPPROCS and OPPROCS attributes for a queue<\/a>.<\/p>\n

Queue status attributes:<\/b><\/p>\n

Attribute: Open input count<\/b>
\nMeaning: This is the number of applications that are currently connected to the queue to get messages from the queue.
\nMQSC parameter: IPPROCS<\/p>\n

Attribute: Open output count <\/b>
\nMeaning: This is the number of applications that are currently connected to the queue to put messages on the queue.
\nMQSC parameter: OPPROCS<\/p>\n

If “endmqm QMgrName” does not effectively end the queue manager, you can try to speed up the shutdown process by adding the flag -i such as:
\nendmqm -i QMgrName<\/i><\/p>\n

For more details, see the product documentation:
\nendmqm<\/a><\/p>\n

The default (endmqm QMgrName) is to use “-c” as in: endmqm -c QMgrName<\/p>\n

-c Controlled (or quiesced) shutdown : <\/b>
\nThis is the default. The queue manager stops, but only after all applications have disconnected. Any MQI calls currently being processed are completed. Control is returned to you immediately and you are not notified of when the queue manager has stopped. The effect on any client applications connected through a server-connection channel is equivalent to a STOP CHANNEL command issued in QUIESCE mode.
\n>> Note: If an application has opened a queue for put or for get, but still is connected, then this will prevent the queue manager from ending. It will remain in “quiescing”.<\/p>\n

-i Immediate shutdown:<\/b>
\nThe queue manager stops after it has completed all the MQI calls currently being processed. Any MQI requests issued after the command has been issued fail. Any incomplete units of work are rolled back when the queue manager is next started.
\nControl is returned after the queue manager has ended.
\nThe effect on any client applications connected through a server-connection channel is equivalent to a STOP CHANNEL command issued in FORCE mode.
\n>> Note: If a client application has opened a queue and still is connected, such as the MQ Explorer, then this option will terminate the server-client connection, allowing the queue manager to terminate.<\/p>\n

-p Preemptive shutdown: <\/b>
\nWARNING: !!!! Use this type of shutdown only in exceptional circumstances. For example, when a queue manager does not stop as a result of a normal endmqm command. !!!<\/p>\n

The queue manager might stop without waiting for applications to disconnect or for MQI calls to complete. This can give unpredictable results for WebSphere MQ applications.
\nThe shutdown mode is set to immediate shutdown. If the queue manager has not stopped after a few seconds, the shutdown mode is escalated, and all remaining queue manager processes are stopped.
\nThe effect on any client applications connected through a server-connection channel is equivalent to a STOP CHANNEL command issued in TERMINATE mode.<\/p>\n

+++ Scenario<\/u><\/b><\/p>\n

The impact that these attributes have whenever they have a value greater than Zero, when trying to terminate the queue manager is best described by a simple scenario, which is described in the rest of this technote.<\/p>\n

A queue Q1 in the queue manager QM_VER has not been opened by any application. Thus, IPPROCS and OPPROCS are 0:
\nIn one window enter:<\/p>\n

$ runmqsc QM_VER<\/tt>
\ndisplay qstatus(Q1)<\/tt>
\n\u00a0 \u00a0 \u00a02 : display qstatus(Q1)<\/tt>
\nAMQ8450: Display queue status details.<\/tt>
\n\u00a0 \u00a0QUEUE(Q1) \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 TYPE(QUEUE)<\/tt>
\n\u00a0 \u00a0CURDEPTH(0) \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 <\/tt>IPPROCS(0)<\/b><\/tt>
\n\u00a0 \u00a0MSGAGE( ) \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 <\/tt>OPPROCS(0)<\/b><\/tt><\/p>\n

In another window, the MQ sample command “amqsput” is issued to put a message:<\/p>\n

$ amqsput Q1 QM_VER<\/tt>
\nSample AMQSPUT0 start<\/tt>
\ntarget queue is Q1<\/tt><\/p>\n

Notice that the text of the message has not being entered yet. The application is just waiting for the user to enter the text. The application has already opened the queue and thus, the counter for OPPROCS has been incremented from 0 to 1:<\/p>\n

$ runmqsc QM_VER<\/tt>
\ndisplay qstatus(Q1)<\/tt>
\n\u00a0 \u00a0 \u00a03 : display qstatus(Q1)<\/tt>
\nAMQ8450: Display queue status details.<\/tt>
\n\u00a0 \u00a0QUEUE(Q1) \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 TYPE(QUEUE)<\/tt>
\n\u00a0 \u00a0CURDEPTH(0) \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 <\/tt>IPPROCS(0)<\/b><\/tt>
\n\u00a0 \u00a0MSGAGE( ) \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 <\/tt>OPPROCS(1)<\/b><\/tt><\/p>\n

In yet another window, the MQ sample command “amqsget” is issued to get a message:<\/p>\n

$ amqsget Q1 QM_VER<\/tt>
\nSample AMQSGET0 start<\/tt><\/p>\n

Notice that now the counter for IPPROCS has been incremented from 0 to 1, and that OPPROCS is still at 1 because amqsput is still connected:<\/p>\n

$ runmqsc QM_VER<\/tt>
\ndisplay qstatus(Q1)<\/tt>
\n\u00a0 \u00a0 \u00a04 : display qstatus(Q1)<\/tt>
\nAMQ8450: Display queue status details.<\/tt>
\n\u00a0 \u00a0QUEUE(Q1) \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 TYPE(QUEUE)<\/tt>
\n\u00a0 \u00a0CURDEPTH(0) \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0<\/tt>\u00a0IPPROCS(1)<\/b><\/tt>
\n\u00a0 \u00a0MSGAGE( ) \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 <\/tt>OPPROCS(1)<\/b><\/tt><\/p>\n

But 30 seconds later, amqsget terminates because no messages arrived within 30 seconds, and now the IPPROCS counter decreased from 1 to 0. But amqsput is still connected, waiting for the user to enter a message and thus OPPROCS is still 1.<\/p>\n

$ runmqsc QM_VER<\/tt>
\ndisplay qstatus(Q1)<\/tt>
\n\u00a0 \u00a0 \u00a03 : display qstatus(Q1)<\/tt>
\nAMQ8450: Display queue status details.<\/tt>
\n\u00a0 \u00a0QUEUE(Q1) \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 TYPE(QUEUE)<\/tt>
\n\u00a0 \u00a0CURDEPTH(0) \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 <\/tt>IPPROCS(0)<\/b><\/tt>
\n\u00a0 \u00a0MSGAGE( ) \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 <\/tt>OPPROCS(1)<\/b><\/tt><\/p>\n

Let’s assume that we wanted to terminate the queue manager, keeping in mind that amqsput is still running and connected to the queue (OPPROCS is still 1):<\/p>\n

$ endmqm QM_VER<\/tt>
\nQuiesce request accepted. The queue manager will stop when all outstanding work
\nis complete.<\/p>\n

Notice that we cannot make new connections, not even running runmqsc:<\/p>\n

$ runmqsc QM_VER<\/tt>
\nAMQ8156: WebSphere MQ queue manager quiescing.<\/tt><\/p>\n

$ amqsget Q1 QM_VER<\/tt>
\nSample AMQSGET0 start<\/tt>
\nMQCONN ended with reason code 2161<\/tt><\/p>\n

$ mqrc 2161<\/tt>
\n\u00a0 \u00a0 \u00a0 2161 \u00a00x00000871 \u00a0MQRC_Q_MGR_QUIESCING<\/tt><\/p>\n

The monitoring of the MQ processes for this queue manager do not show any changes and the processes are still running.<\/p>\n

$ ps -ef | grep -i QM_VER<\/tt>
\nmqm \u00a0 \u00a0 \u00a0 1869 \u00a0 \u00a0 1 \u00a00 13:28 ? \u00a0 \u00a0 \u00a0 \u00a000:00:00 amqzxma0 -m QM_VER<\/tt>
\nmqm \u00a0 \u00a0 \u00a0 1874 \u00a01869 \u00a00 13:28 ? \u00a0 \u00a0 \u00a0 \u00a000:00:00 \/opt\/mqm\/bin\/amqzfuma -m QM_VER<\/tt>
\nmqm \u00a0 \u00a0 \u00a0 1878 \u00a01869 \u00a00 13:28 ? \u00a0 \u00a0 \u00a0 \u00a000:00:00 amqzmuc0 -m QM_VER<\/tt>
\nmqm \u00a0 \u00a0 \u00a0 1884 \u00a01869 \u00a00 13:28 ? \u00a0 \u00a0 \u00a0 \u00a000:00:00 amqzmur0 -m QM_VER<\/tt>
\nmqm \u00a0 \u00a0 \u00a0 1885 \u00a01869 \u00a00 13:28 ? \u00a0 \u00a0 \u00a0 \u00a000:00:00 amqzmuf0 -m QM_VER<\/tt>
\nmqm \u00a0 \u00a0 \u00a0 1888 \u00a01869 \u00a00 13:28 ? \u00a0 \u00a0 \u00a0 \u00a000:00:00 \/opt\/mqm\/bin\/amqrrmfa -m QM_VER -t2332800 -s2592000 -p2592000 -g5184000 -c3600<\/tt>
\nmqm \u00a0 \u00a0 \u00a0 1889 \u00a01869 \u00a00 13:28 ? \u00a0 \u00a0 \u00a0 \u00a000:00:00 \/opt\/mqm\/bin\/amqzdmaa -m QM_VER<\/tt>
\nmqm \u00a0 \u00a0 \u00a0 1914 \u00a01869 \u00a00 13:28 ? \u00a0 \u00a0 \u00a0 \u00a000:00:00 \/opt\/mqm\/bin\/amqzmgr0 -m QM_VER<\/tt>
\nmqm \u00a0 \u00a0 \u00a0 1928 \u00a01869 \u00a00 13:28 ? \u00a0 \u00a0 \u00a0 \u00a000:00:00 amqzlaa0 -mQM_VER -fip0<\/tt>
\nrivera \u00a0 \u00a02484 19416 \u00a00 13:28 pts\/3 \u00a0 \u00a000:00:00 amqsput Q1 QM_VER<\/tt>
\nrivera \u00a0 \u00a03605 19796 \u00a00 13:30 pts\/4 \u00a0 \u00a000:00:00 grep -i QM_VER<\/tt><\/p>\n

Because an amqsput connection is preventing the queue manager from terminating, only until amqsput terminates, the queue manager will end.<\/p>\n

One easy solution is to manually terminate amqsput, which will disconnect from the queue (OPPROCS will be 0) and the queue manager will terminate.<\/p>\n

However, sometimes, it is not easy to identify which is the particular application that is preventing the shutdown, then it is OK to escalate the shutdown of the queue manager by issuing “-i” (for immediate).
\nThus, in the same window or in another window, issue the following command, even though an “endmqm QMgrName” was issued already (but it is quiescing).<\/p>\n

$ endmqm -i QM_VER<\/tt>
\nWebSphere MQ queue manager 'QM_VER' ending.<\/tt>
\nWebSphere MQ queue manager 'QM_VER' ended.<\/tt><\/p>\n

The “-i” flag will wait for in transit activities to terminate, but because there are none at this time, then it will terminate the connection of amqsput and then continue successfully to terminate the queue manager.<\/p>\n

Notice that the pending amqsput is terminated with rc 2009:<\/p>\n

$ amqsput Q1 QM_VER<\/tt>
\nSample AMQSPUT0 start<\/tt>
\ntarget queue is Q1<\/tt>
\nMQCLOSE ended with reason code 2009<\/tt>
\nSample AMQSPUT0 end<\/tt><\/p>\n

Notice that the rc 2009 means:
\n$ mqrc 2009<\/tt>
\n\u00a0 \u00a0 \u00a02009 \u00a00x000007d9 \u00a0MQRC_CONNECTION_BROKEN<\/tt><\/p>\n<\/div>\n<\/div>\n

<\/div>\n
\n

Product Alias\/Synonym<\/h2>\n

WebSphere MQ WMQ<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

Problem(Abstract) <\/p>\n

You notice that when the WebSphere MQ (WMQ) queue attributes of IPPROCS or OPPROCS are greater than 0, and try to end the queue manager by issuing “endmqm QmgrName”, then the queue manager goes into “quiescing” but it does not fully terminate.<\/p>\n

Is there a way to speed up the shutdown of the […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[57],"tags":[],"_links":{"self":[{"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/posts\/6488"}],"collection":[{"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mohan.sg\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=6488"}],"version-history":[{"count":1,"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/posts\/6488\/revisions"}],"predecessor-version":[{"id":6489,"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/posts\/6488\/revisions\/6489"}],"wp:attachment":[{"href":"https:\/\/mohan.sg\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=6488"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mohan.sg\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=6488"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mohan.sg\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=6488"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}