Peter,
I've told you why. Did you read my mail. I know that the sender channel
will keep retrying and that a client will get a 2059 but compare the error
messages written to the log.
Cheers,
P.
Paul G Clarke
WebSphere Messaging Clients
IBM Hursley
"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
10/03/2005 13:13
Please respond to
MQSeries List
Its not a big deal really. We do add endmqlsr next to endmqm in the
shutdown
script. We were just talking this out and the question came up - Why do we
have to take the extra step of ending the listener separately?
SNDR channels stay retrying whether you have (QM down / Listener up) or (QM
down / Listener down).
MQClients get 2059 whether you have (QM down / Listener up) or (QM down /
Listener down).
So I still wonder what good a listener is without a running QM, and by
extension, why doesn't endmqm then just kill the listener(s) also?
Its more of a curiosity at this point, wondering if I am not understanding
something. The workaround is easy enough.
-Peter
-----Original Message-----
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf
Of Paul Clarke
Sent: Thursday, March 10, 2005 4:54 AM
To: [email protected]
Subject: Re: amqmdain options for ending a QM
Peter,
Personally I on't agree that a listener running without a QM running is
useless. It allows MQ on the receiving box to respond to incoming requests.
If you bring the listener down then anyone trying to connect to you, client
or sender channel, will just get a communications error. This can be
disconcerting and can lead people to wonder whether their
configuration/network is working. With the listener running you get a nice
message saying something about QM not available or channel not available
etc please retry later.
Not sure I understand your first point either; I thought the concern was
about ending listeners while the QM was still running not when it's ended.
endmqlsr should work fine once you've brought the QM down. So, if you
really want your listener to come up and down with your QM just wrap the
start/stop in a script and add something like 'endmqlsr -w'
Cheers,
P.
Paul G Clarke
WebSphere Messaging Clients
IBM Hursley
MQSeries List <[email protected]> wrote on 10/03/2005
00:02:14:
> OK, this explains why you would not end the listener while the QM is up.
But
> it does not explain why a listener remains after endmqm. You wouldn't
have
> the problem that Paul speaks of to begin with if the listener was forced
to
> come up and down with the QM.
>
> A listener with no QM running is useless, so why doesn't endmqm kill the
> runmqlsr processes? endmqm gets rid of amqzfuma, amqzlaa0, etc. What so
> special about runmqlsr that IBM chose not to have endmqm take it down as
> well?
>
>
>
>
>
> -----Original Message-----
> From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf
> Of Chan, Ian M
> Sent: Wednesday, March 09, 2005 6:07 PM
> To: [email protected]
> Subject: Re: amqmdain options for ending a QM
>
>
> Peter,
>
> I had this question a year ago when I moved from inetd to runmqlsr. I
put
> that question to the list and PC provided the answer below.....It's
always
> useful to keep PC's mail.
>
> Regards,
>
> Ian
>
> **********************
>
> The reason why we're not keen on people ending listeners while the Queue
> Manager is active is because quite a number of customers run their
channels
> fastpath. Ending a program when there are fastpath applications which may
be
> issuing MQ calls when the process ends is potentially hazardous. Not too
> hazardous but still hazardous. In some cases it may be necessary to bring
> the QM down and restart. If we force the user to end the Queue Manager
> before ending the listener then clearly we never get into this situation.
>
> Now, I'm not a huge fan of this restriction and it's somewhat pointless
> since the user can just go into task manager and kill the listener or
issue
> Kill -9 anyway.
>
> So, you guys know me. If I don't like the 'official' line I tend to bend
it
> slightly. So, just between you and me, if you add a -f parameter to your
> endmqlsr command you might find it does it anyway - even if the Queue
> Manager is still running. Don't tell anybody though will you. -f stands
for
> 'force' of course.
>
> Cheers,
> P.
>
> *********************
>
>
>
>
> -----Original Message-----
> From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf
Of
> Potkay, Peter M (ISD, IT)
> Sent: Thursday, 10 March 2005 8:48 AM
> To: [email protected]
> Subject: Re: amqmdain options for ending a QM
>
> You get the same error (2059) if both the QM AND the Listener are not
> running together.
>
> So if the QM is up and the listener is down, the QM is down and the
listener
> is up, or both are down, you still get a 2059.
>
> Any other ideas as to the benefit of a listener without a QM?
>
>
>
> -----Original Message-----
> From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf
Of
> Michael Dag
> Sent: Wednesday, March 09, 2005 4:04 PM
> To: [email protected]
> Subject: Re: amqmdain options for ending a QM
>
>
> So it can tell connecting clients the qmgr is not available?
>
>
> -----Original Message-----
> From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf
Of
> Potkay, Peter M (ISD, IT)
> Sent: woensdag 9 maart 2005 21:38
> To: [email protected]
> Subject: Re: amqmdain options for ending a QM
>
> OK, but that still doesn't explain why runmqlsr isn't killed with endmqm.
a
> dozen other mq processes go away with endmqm, why not the listener. Why
> would you have a listener running if the QM was not?
>
>
>
> -----Original Message-----
> From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf
Of
> Pavel Tolkachev
> Sent: Wednesday, March 09, 2005 3:16 PM
> To: [email protected]
> Subject: Re: amqmdain options for ending a QM
>
>
> You can do whatever you want to the queue manager files (like
> backup/restore) while queue manager is down, whether the listener is up
or
> not. Think of inetd.. it is always kinda running and configured to fire
> amqrsta but it is seldom a problem (sometimes it is though...).
>
> Just 2 c
> Pavel
>
>
>
>
>
>
> "Potkay, Peter M (ISD, IT)" <[EMAIL PROTECTED]>
> Sent by: MQSeries List <[email protected]>
>
> To
>
> [email protected]
> 03/09/2005 03:03 PM
> cc
>
>
> Subject
>
> Please respond to
> Re: amqmdain options for ending a QM
>
> MQSeries List <[email protected]>
>
>
>
>
>
>
>
>
>
> What is the logic of endmqm not also bringing down the listener? What
good
> is a listener without a QM?
>
>
> -----Original Message-----
> From: MQSeries List [mailto:[EMAIL PROTECTED]
> Behalf Of Russell Finn
> Sent: Friday, January 21, 2005 10:28 AM
> To: [email protected]
> Subject: Re: amqmdain options for ending a QM
>
>
> Yes, it is "safe" to use endmqm -i to stop a queue manager that was
> started using amqmdain
>
> Russell
>
> Russell Finn
> MQSeries System Test
>
> [EMAIL PROTECTED]
>
>
> "Potkay, Peter M (ISD, IT)" <[EMAIL PROTECTED]> Sent by:
> MQSeries List <[email protected]>
>
>
> To
> 21/01/2005 01:26
> [email protected]
>
> cc
>
>
> Please respond to
> Subject
>
> MQSeries List
> Re: amqmdain options for ending a QM
>
>
>
>
>
>
>
>
>
>
>
>
> 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
>
> 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
>
>
>
> *************************************************************************
> PRIVILEGED AND CONFIDENTIAL: This communication, including attachments,
is
> for the exclusive use of addressee and may contain proprietary,
confidential
> and/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 e-mail, 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
>
>
>
>
>
> --
>
> This e-mail may contain confidential and/or privileged information. If
you
> are not the intended recipient (or have received this e-mail in error)
> please notify the sender immediately and destroy this e-mail. Any
> unauthorized copying, disclosure or distribution of the material in this
> e-mail is strictly forbidden.
>
> 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
>
> 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
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
