| Author |
Message
|
| slonkoski |
 Posted: Sat Apr 19, 2014 7:32 am Post subject: Struggling to delete remote queue in use |
 |
|
Acolyte
Joined: 18 Mar 2005
Posts: 52
|
Hi, I have a v7.0.1.6 QMGR and I need to delete some RQ's that are in use by unknown applications. I tried 'DIS QS(QM1.RQ) but of course get 'Unknown object name.'
All of the RQ's on this QMGR use the same xmitq so 'DIS QS(QM2.XMITQ) type(handle) channel' or 'pid' or 'apptag' won't help as I get all the current users, not just the ones I want for certain RQ's. I was hoping to determine the channel that the connecting app is using to connect to the RQ on QM1 so I could simply stop it and delete the RQ.
I thought about PUT DISABLE but if the app already connected and has it open that won't help as I need to get these deleted quickly (part of a change control I'm working on in a tight window)
Thoughts? |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Sat Apr 19, 2014 9:32 am Post subject: Re: Struggling to delete remote queue in use |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9396
Location: US: west coast, almost. Otherwise, enroute.
|
| slonkoski wrote: |
| Hi, I have a v7.0.1.6 QMGR and I need to delete some RQ's that are in use by unknown applications. |
Do you mean that you need to delete QRemote definitions? Or that you need to delete QLocal definitions that are known to the cluster?
I ask because you posted this in the Clusters forum.
If you want to take a QLocal out of the cluster (so it won't be used by new applications), the usual process is to:
- alter the QLocal definitions to specify CLUSTER(' ').
- wait until all currently connected applications have closed the queue(s)
- if some long-running apps don't close the queue(s), you will need put disable the queue(s) before you can
- delete the queue
In any case, the application developers will likely discover that you have deleted the queue(s) the next time the app is executed. So, why do you want to delete the queues?
_________________
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 |
|
|
| slonkoski |
| Posted: Sat Apr 19, 2014 11:49 am Post subject: Oops, no, not really a cluster issue per se |
|
|
Acolyte
Joined: 18 Mar 2005
Posts: 52
|
The RQ is on QM1 - it is pointed to a local queue on QM2/QM3 that is clustered, I don't want to touch those queues. I am deleting the current RQ and replacing it with an alias queue. This is one of the steps for migrating to WMBv8, the current RQ points to clustered q's in a v6 WMB cluster but they route thru a 'gateway' server that sprays messages into the cluster. For v8 we simply clustered all the QMGR's eliminating the GW and let the clustering SW load balance.
Bottom line I may not have a contact or know what app has a particular queue open when I'm ready to delete it and replace with an Alias queue, so was hoping there was a way to 'force' delete the RQ or identify which channel has it open so I can stop the channel and delete the RQ.
How do I move this to regualr MQ question section? |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Apr 19, 2014 4:20 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
Moved to the General MQ Support Forum
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Apr 19, 2014 4:31 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
If the remote queue is called APP1.REQUESTQ, you may get lucky if it has a corresponding local queue called APP1.REPLYQ. Do a QSTATUS on the local reply queue and odds are it will be the same client channel that has the remote queue open.
And/or
Try the Put Disable of the Remote Queue. You might get lucky and the app does puts to it frequently - the next MQPUT it attempts will fail and hopefully the app pukes and closes the queue and disconnects.
Other than these 2 hail mary attempts, I think you are right - if an app is holding a remote queue open, MQ 7.0 does not give the MQ Admin any methods to deduce what app or client channel has the remote queue (or alias queue) open. Stop the most likely client channel baed on name and hope? Put disable the q and restart the queue manager? Ugh.
Yeah, yeah, yeah, just go to the reference library that holds every detail about every app that ever existed in your company and check there for the app and channel name that uses that remote queue. OK, how about for the rest of us in the real world - any trick to determine what client channel has a remote queue open?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Apr 19, 2014 4:38 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
I don't have access to a system to try this right now, but what about displaying the channel status with all attributes for all active client channels - does that show queue names? I don't think so, but check.
What about the DISPLAY CONN command? It has OBJNAME (object name) as one of the handle attributes. Maybe display all the connections to the QM, sort by the OBJNAME column and maybe it will show the remote queue name there - giving you the connection, from which you should be able to find the channel?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| slonkoski |
| Posted: Sun Apr 20, 2014 4:59 am Post subject: |
|
|
Acolyte
Joined: 18 Mar 2005
Posts: 52
|
| Good thought on the DIS CONN but no cigars, close! At this point unless someone knows an undocumented trick I'm out of luck. |
|
| Back to top |
|
|
| tczielke |
| Posted: Sun Apr 20, 2014 6:43 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 939
Location: Illinois, USA
|
If the connecting app is putting often to the remote queue, you can probably track down the channel (and other application information) with strmqtrc.
For example, if all the channels that have XMITQ that your QR points to are running on amqrmppa processes, then you can do the following:
strmqtrc -m QM1 -t api -p amqrmppa
If this is Unix, use dspmqtrc to format the trace.
Then search for the first 16 bytes of your remote queue name. You should see the queue remote name in the Putmsgopts of the MQPUT and the trace also lists the channel name that is performing the PUT. It at least does this in the 7.1 and 7.5 traces. |
|
| Back to top |
|
|
| slonkoski |
| Posted: Sun Apr 20, 2014 8:39 am Post subject: |
|
|
Acolyte
Joined: 18 Mar 2005
Posts: 52
|
| Thank you, that will work! These are very busy QMGR's with many amqrmppa's so multiplie large trace files to grep, but at least I now have a way to determine the channel being used! Again, thank you very much! |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sun Apr 20, 2014 2:38 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
This will only show future MQOPENs / MQPUTs against the remote queue, in which case one of the already mentioned methods would work. It won't help identify a queue already open, but not being put to.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| tczielke |
| Posted: Sun Apr 20, 2014 2:49 pm Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 939
Location: Illinois, USA
|
| Quote: |
| It won't help identify a queue already open, but not being put to. |
That is true. However, for slonkoski's use case, it sounds like he has an app that has the remote queue previously opened, but is still continuing to PUT often to the remote queue. For that use case, the strmqtrc approach should be helpful in determining the channel that is doing the putting to the remote queue.
slonkoski - One other note. If the channel name is not readily available in the trace, you will be able to see the pid.tid (on the left side of the trace records) that is doing the PUT. You can use a DIS QS TYPE(HANDLE) on the XMITQ to see which channel that pid.tid ties to. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sun Apr 20, 2014 2:53 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
Here's a way that works.
Fire up MO71.
Go to Connection List.
Change the drop down for Connection Info to All.
Right click in the area where the list of results will show and make sure CONN, CHANNEL and OBJNAME are selected. You can probably select all columns to display on QMs that don't have too many connections. But be careful about asking for all columns on a QM with thousands of connections. It will take forever to return the results. And all the results may not fit in your MO71 temp dyn queue depending on how big you make them.
Hit Refresh.
Sort the results by Connection ID.
One row will show your queue name. Even a remote queue definition.
And the partner row, the one with the same connection ID, will show the channel name.
MQ is kewl. 
MO71 is
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| slonkoski |
| Posted: Mon Apr 21, 2014 3:30 am Post subject: |
|
|
Acolyte
Joined: 18 Mar 2005
Posts: 52
|
That's what I like - options! 2 solutions, I have MO71 and it makes this task very easy, thank you Peter and tczielke!
I'll go with MO71 for this task, quick and easy. I'll admit I hadn't played much with trace like tczielke suggested, learn something new everyday. I will add this to my bag-o-tricks for future use. thank you all for the great help! |
|
| Back to top |
|
|
| tczielke |
| Posted: Mon Apr 21, 2014 6:23 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 939
Location: Illinois, USA
|
Thanks for the tip Peter on MO71. We do not have MO71 at our shop, but this type of functionality is definitely a reason to pursue purchasing it.
My understanding is that MO71 is a client application that would connect to the queue managers (i.e. no agent installed on the same server as the queue manager). With only an MQI channel, I am struggling to see how MO71 would be able to determine this type of information queue remote information. But definitely very cool that it can. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Apr 21, 2014 6:58 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| tczielke wrote: |
| We do not have MO71 at our shop, but this type of functionality is definitely a reason to pursue purchasing it. |
When did they start charging for MO71? 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
