| Author |
Message
|
| belchman |
 Posted: Thu Apr 13, 2006 9:19 am Post subject: Is there a way to release a 2042 situation |
 |
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
The PID that did open exclusive is dead (no longer on box) and the q is open exclusive by pid.
Is there a way to release lock w/o bouncing QM?
mq ver 5.3.12 |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Thu Apr 13, 2006 9:25 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
does dis qstatuts(...) type(handle) show you the old PID?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| belchman |
| Posted: Thu Apr 13, 2006 9:26 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
|
| Back to top |
|
|
| belchman |
| Posted: Thu Apr 13, 2006 9:29 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
| Hold, don't act on that YES yet. Let me look again. |
|
| Back to top |
|
|
| belchman |
| Posted: Thu Apr 13, 2006 9:32 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
No...
dis qstatus(foo)
2 : dis qstatus(foo)
AMQ8450: Display queue status details.
QUEUE(foo) IPPROCS(1)
OPPROCS(1) CURDEPTH(0)
UNCOM(NO)
dis qstatus(foo) TYPE(HANDLE)
3 : dis qstatus(foo) TYPE(HANDLE)
AMQ8450: Display queue status details.
QUEUE(foo)
AMQ8450: Display queue status details.
QUEUE(foo) |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Apr 13, 2006 9:32 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Is it a bindings connection, or a client connection?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| belchman |
| Posted: Thu Apr 13, 2006 9:35 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
Windows client.
However,
MQ Monitor (IBM support pac type), shows that the q is open exclusive by a PID that died and is no longer on MQ host. The process died prior to disc. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Apr 13, 2006 9:36 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If it's a client connection that the application used to open the queue, then you can stop the svrconn channel instance, and that should release the lock.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| belchman |
| Posted: Thu Apr 13, 2006 9:39 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
Thanks man,
We thought of that but all clients using that channel are not 2042'd. They go to diff queues. If we bounce channel then the impact of outage goes way up. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Apr 13, 2006 9:50 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Yes, but you don't have to bounce the QM! 
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| belchman |
| Posted: Thu Apr 13, 2006 9:55 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
| Very good point. I appreciate your input. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Apr 13, 2006 10:03 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
There might be a way to kill the individual channel instance - but I don't remember v5.3 details that well. And it might only be in v6 that you can do this - at least in v6 you can kill the app connection itself rather than the channel instance.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| belchman |
| Posted: Thu Apr 13, 2006 10:11 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
One other point,
The PID that has the lock on the queue is the PID for a dead AMQRMPPA process. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Apr 13, 2006 10:17 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Ooo... That's "Process pooling process".
You may be in more trouble than I thought - and I didn't see your initial append that the PID was not your application.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Apr 13, 2006 3:10 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
u might try GET INHIBITING the queue. That sometimes works. It does when the orphaned pid is a phantom Channel Init. That'sa because the orphaned process was written to try and MQGET rather often, and was written to terminate when it got a GET Inhibited error.
But, if that doesn't work, and the PID in question is not in Task Manager for you to Kill, then you are S.O.L. and will have to bounce the QM to release it.
Also, start creating a dedicated SVRCONN channel for each app, so that if u ever do have to stop a chanel, u effect that one app and not multiples. Not that that would have helped you here.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
