I was writing shutdown and startup scripts for the MSCS and non-MSCS
environments here. (Cute scripts). I wanted to use amqmdain, after testing,
found what Peter found. I went to endmqm. I would have preferred the
amqmdain because it takes care of anything that is defined for the Queue
Manager under the Services window. Plus it is cleaner. Peter, if they come
back with an implementation let us know.

                                                  bobbee

From: [EMAIL PROTECTED]
Reply-To: MQSeries List <[email protected]>
To: [email protected]
Subject: Re: amqmdain options for ending a QM
Date: Fri, 21 Jan 2005 11:43:30 +1100

Hi Peter,

If you need the endmqm -i behaviour, could you not just run endmqm -i
rather than end the queue manager using amqmdain. You can still use
amqmdain to restart the queue manager in order to avoid the disastrous
behaviour exhibited with strmqm on windows (queue manager crash when the
user logs out).


Regards,

Neil Casey
National Australia Bank
Southern Star Technology
WebSphere MQ Support
1/122 Lewis Rd Wantirna South
office. +61 3 9886 2375 (x82375)
mobile. +61 414 615 334



             "Potkay, Peter M
             (ISD, IT)"
             <[EMAIL PROTECTED]                                          To
             HARTFORD.COM>             [email protected]
             Sent by: MQSeries                                          cc
             List
             <[EMAIL PROTECTED]                                     Subject
             V.MEDUNIWIEN.AC.A         Re: amqmdain options for ending a
             T>                        QM


21/01/2005 10:17


Please respond to MQSeries List <[EMAIL PROTECTED] V.MEDUNIWIEN.AC.A T>






So, IBM confirmed that amqmdain acts like a Controlled shutdown, and there is no way to make it act like endmqm -i. I opened up a request for adding this option, and got the following response: >>amqmdain should support an immediate (not just controlled) shutdown of the QM Accepted- IBM agrees with the request and a solution is desirable and feasible. IBM intends to provide a solution. However, IBM's plans may change, and no commitment is made that a solution will be provided.


But, I still wonder why my Client Concentrator takes sooooooooo long to end if I use amqmdain end. On the QM where there are few clients connected, it comes down in about a minute. On the QM that has a couple of hundred of clients connected, it takes 45 minutes !!! And all 3 error logs (at 1MEG each) are filled with errors saying the channels are ending, that QM is ending, etc.

I really would like to be able to bring this Windows QM down every night.
What I don't understand is why does the QM take so long to end. Could it be
the barrage of reconnect attempts?




---------------------------------------------------- Potkay, Peter M (ISD, IT) Thu, 21 Oct 2004 08:41:50 -0700

Does a client app that connects and then does MQOPENs / MQGETs without the
FAIL_IF_QUEISCING option prevent a QM from coming down if I use amqmdain?


amqmdain end MyQM

Is that the same as endmqm -i, or endmqm -c?

My QM would not end using this command, and we had to reboot the server.
Windows 2000 MQ 5.3 CSD04

My logfile for the amqmdain end MyQM throws the error:
ERROR: could not get the task list

The error logs show this all night:
----- amqrmrsa.c : 467
--------------------------------------------------------
10/21/2004 02:46:55
AMQ9508: Program cannot connect to the queue manager.

EXPLANATION:
The connection attempt to queue manager 'HIGIAOD1' failed with reason code
2161.
ACTION:
Ensure that the queue manager is available and operational.
----- amqrmsaa.c : 425
--------------------------------------------------------
10/21/2004 02:46:55
AMQ9999: Channel program ended abnormally.

EXPLANATION:
Channel program 'CDS.CALLIGO' ended abnormally.
ACTION:
Look at previous error messages for channel program 'CDS.CALLIGO' in the
error
files to determine the cause of the failure.
----- amqrmrsa.c : 467
--------------------------------------------------------

Using TransactionVision, I see today that the app connecting over this
channel is issuing MQGETs without FAIL_IF_QUIESCING, as well as the
occasional MQOPEN that is done, also without FAIL_IF_QUIESCING.


> Peter Potkay > MQSeries Specialist > The Hartford Financial Services > [EMAIL PROTECTED] > x77906 > IBM MQSeries Certified >


This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies.

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>


This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies.

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

Reply via email to