Hi Folks, a way to stop is issueing cpf<qmgr> STOP QMGR MODE=FORCE
Take a look on the command in the manual..... it's no so dangours as it look like, it might just do what you want.... I guess. ;o) I takes the queue manager down and keeps the integraty. Best regards Joergen H. Pedersen Systemprogrammer WM-data SDC [EMAIL PROTECTED] IBM Certified MQSeries Specialist IBM Certified MQSeries Solutions Expert Please apply this disclaimer to the above message - the opinions are mine and certainly not necessarily those of my employer. "Miller, Dennis" <[EMAIL PROTECTED]>@AKH-Wien.AC.AT> on 14-11-2002 18:34:14 Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: Re: Detecting MQ subsystem shutdown What's the rationale for hanging the qmgr just because there's an app with open connection is not currently in the midst of an API request? I mean, it COULD be a long time before the app needs MQ services. Or it COULD be a long time before the app cooperates and closes the connection. So, it appears we have this: 1. Qmgr shutdown is issued 2. Qmgr hangs because of open connection 3. Application eventually issues an MQ call 4. Call fails with MQ quiescing 5. Application closes connection 6. Qmgr shutsdown When this seems much more sensible: 1. Qmgr shutdown is issued 2. Qmgr abandons the connection and shutsdown 3. Application eventually issues an MQ call 4. Call fails with Qmgr not available I'm with bobee--I still find it funny that the QMGR doesn't just drop the connection! In fact, that should happen even if there is uncommitted work because there is no way to actually commit at that point. > -----Original Message----- > From: John Scott [SMTP:[EMAIL PROTECTED]] > Sent: Wednesday, November 13, 2002 3:47 PM > To: [EMAIL PROTECTED] > Subject: Re: Detecting MQ subsystem shutdown > > >From: Robert Broderick [mailto:robertbroderick@;HOTMAIL.COM] said... > <SNIP/> > >I still find it funny that the QMGR doesn't drop the connection if you > don't > >have any uncommited work going on!! > > If he's not got an MQI call in progress (he's doing something else) then > it > won't fail because he's not waiting on MQ which can fail his call. I would > assume the call would fail the next time an MQI call is performed. > > Cos' it's OS/390, I am not to sure how you would get it to stop > immediately > (endmqm -i on distributed) which would get it to stop and leave the > connected app behind to fail on the next MQI call. > > John. > > > ********************************************************************** > > Click here to visit the Argos home page http://www.argos.co.uk > > The information contained in this message or any of its attachments may be > privileged and confidential, and is intended exclusively for the > addressee. > The views expressed may not be official policy, but the personal views of > the originator. > If you are not the intended addressee, any disclosure, reproduction, > distribution, dissemination or use of this communication is not > authorised. > If you have received this message in error, please advise the sender by > using your reply facility in youe e-mail software. > All messages sent and received by Argos Ltd are monitored for virus, high > risk file extensions, and inappropriate content. As a result users should > be aware that mail maybe accessed. > > ********************************************************************** > > Instructions for managing your mailing list subscription are provided in > the Listserv General Users Guide available at http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
