| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| CSQ4MSTR won't shut down |
« View previous topic :: View next topic » |
| Author |
Message
|
| zhanghz |
 Posted: Wed Sep 02, 2009 12:38 am Post subject: CSQ4MSTR won't shut down |
 |
|
Disciple
Joined: 17 Jun 2008
Posts: 186
|
I have this z/OS qmgr CSQ4. I issued the +CSQ4 STOP QMGR, the CSQ4CHIN was shut down successfully, but CSQ4MSTR halts after the qmgr did DISPLAY USAGE TYPE(ALL). It just don't shut down. It's been like this for 1.5 hours.
I encoutered similar case before. If I issue a STOP QMGR MODE(FORCE), the qmgr will be shut down.
I don't know what the qmgr is doing. What should I check now? I have confirmed that there is no user in MQ pannel.. I did a DIS CONN, there are 17 connections, all with URTYPE(QMGR) and APPLTYPE(SYSTEM). But I don't know whether this is normal.
Thanks. |
|
| Back to top |
|
 |
| Mr Butcher |
| Posted: Wed Sep 02, 2009 1:08 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
if you only use "STOP" the qmgr starts it*'s shutdown, but waits for all applications (threads) that are connected to disconnect. Applications therfore should use fail-if-quiescing as option e.g. in get-wait so they get notified about the qmgr shutdown.
if they don't do, of if they do not react properly and end their work they will stay connected, so your qmgr will not shut down.
Using MODE(FORCE) will make MQ terminate these threads and rollback open units of work, so no special recovery is needed during restart.
Use a DIS THREAD(*) to identify applications that do not disconnect after issuing the STOP command. (sometimes you will find yourself using CSQOREXX Panels  ). Then talk with developement to include that fail_if_quiescing option.
if doing qmgr shutdown by system automation, we implement stop qmgr first, and then, if mq does not terminate after a specified time, the next command issued is the stop qmgr mode(force)
_________________
Regards, Butcher |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Sep 02, 2009 5:54 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
This is common when developers code MQGET with WAIT and WAITINTERVAL of forever (or some other irrational WAITINTERVAL).
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| zhanghz |
| Posted: Wed Sep 02, 2009 4:44 pm Post subject: |
|
|
Disciple
Joined: 17 Jun 2008
Posts: 186
|
| I DISplayed CONNections, all "SYSTEM" connection. Say if there is an application connected with MQ and wouldn't want to release the connection, the CONNection entry should be something like "CICS", "BATCH", chinit ID, right? But what I got were all SYSTEM connections. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Sep 02, 2009 5:41 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zhanghz wrote: |
| Say if there is an application connected with MQ and wouldn't want to release the connection, the CONNection entry should be something like "CICS", "BATCH", chinit ID, right? |
Why? If the application is badly coded enough to have an indefinate wait and not respond to a quiese command, why wouldn't it be using a SYSTEM connection which is equally bad practice?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Wed Sep 02, 2009 9:45 pm Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
could you please post the command you use and the output for these connections?
_________________
Regards, Butcher |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
