Huh. I never thought of that. Good idea Neil....

Using endmqm -i QM1, the QM, channel init and command server did come down,
but the listener was left running. So I then issued endmqlsr -m QM1, and the
listener ended.

amqmdain then was able to start the QM back up, and the channel init command
server and the listener started up.

I have always been told never to mix the command line commands with
amqmdain/MQServices, but this seems OK.

Anyone else care to comment? Until amqmdain supports -i, is this a safe way
to do it?


-----Original Message-----
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf
Of [EMAIL PROTECTED]
Sent: Thursday, January 20, 2005 7:44 PM
To: [email protected]
Subject: Re: amqmdain options for ending a QM


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


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

Reply via email to