| Author |
Message
|
| Ross |
 Posted: Fri Jan 12, 2007 4:17 am Post subject: How to Close a Queue on z/OS |
 |
|
Centurion
Joined: 15 Jun 2005
Posts: 127
Location: Ireland
|
Hi,
I have an application programmer whose app was cancelled, leaving a local queue in an OPEN state, with uncommitted messages in the queue.
The app will not run now and I believe it may work if we can get this commit and close issued. The app is failing with ¦R¦0000¦MQOPEN CALL¦REQUEST QUEUE OPEN FAILURE.
Can I close this queue or does it have to be issued at application level?
This is z/OS - WMQ V5.3.1
Thanks,
Ross. |
|
| Back to top |
|
 |
| Mr Butcher |
| Posted: Fri Jan 12, 2007 5:07 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
If an application was cancled the MQ cleanup should perform all proper actions, including rollback (backout) of changes (if you work under syncpoint). also the queue should be closed and not show up open any longer. if the queue is still open and you are sure the application has terminated then you should report this to ibm.
there is no way you can use a program, connect and just close the queue.
i remember i also was faced with situation like this where the queue remains open, but that was years ago (okay, this does not mean it can not occur today  )
report to ibm (maybe they got other hints what to check)
take a dump
restart mq
if you dont care for abends you could try a "DISPLAY THREAD(*) TYPE(INDOUBT)", maybe the application thread shows up and you can try a "RESOLVE INDOUBT" with backout, but thats nothing i would try in production. The most cases i found MQ failing on z/OS was during backout actions, and in this special situation you already have a failing backout.
make sure the application that was cancled has terminated. sometimes a cancle does not work and the job stays in the system (and has to be forced)
_________________
Regards, Butcher |
|
| Back to top |
|
|
| Ross |
| Posted: Fri Jan 12, 2007 5:37 am Post subject: |
|
|
Centurion
Joined: 15 Jun 2005
Posts: 127
Location: Ireland
|
The batch job was cancelled, so it was not a clean ending.
There is still an OPEN.
I am looking for a way to manually close this connection, but I am unaware of a way to do this with recycling the qmgr. I don't want to do this. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Fri Jan 12, 2007 5:43 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
yes, i understood that the job was cancled. MQ should do the backout and cleanup, but looks like it failed.
did you try the display thread command i posted?
i only can repeat - from my experience you can not close this manually. just tricks. so report it to ibm.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| KevinF23492 |
| Posted: Fri Jan 12, 2007 6:12 am Post subject: |
|
|
Novice
Joined: 26 Dec 2006
Posts: 22
|
| Quote: |
The batch job was cancelled, so it was not a clean ending.
There is still an OPEN.
I am looking for a way to manually close this connection, but I am unaware of a way to do this with recycling the qmgr. I don't want to do this. |
During ABEND processing (which is essentially what cancelling the job does) z/OS should clean up after the failing program in much the same way that it does with datasets that were open. I have seen instances where the connection handle has been left 'active', but this gets cleaned up after a few minutes.
I am little unsure as to if you mean the connection is left open, or the queue itself is left open. Initially you started talking about a queue left open, but in this last entry you are asking about the connection.
If the queue is staying 'open' then you need to raise an APAR. We are 5.3.1 and we don't have this issue....and trust me, our programmers write failing code all the time  |
|
| Back to top |
|
|
| Ross |
| Posted: Fri Jan 12, 2007 6:51 am Post subject: |
|
|
Centurion
Joined: 15 Jun 2005
Posts: 127
Location: Ireland
|
The display indoubt gave no response.
I can identify the thread.
I ideally want to be able to cancel/close this open thread. |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Jan 12, 2007 6:58 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
What open thread? Mainframes have address spaces and tasks.
What has the queue open (press PF11 on the 3270 display of the queue)? |
|
| Back to top |
|
|
| Ross |
| Posted: Fri Jan 12, 2007 7:07 am Post subject: |
|
|
Centurion
Joined: 15 Jun 2005
Posts: 127
Location: Ireland
|
The queue has 1 open handle/thread, shown by F11 in CSQOREXX.
This is a batch job that was cancelled. F11 shows this job name, but the job is no longer active. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Fri Jan 12, 2007 7:35 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
something makes me feel you do not really read the answers you get. 
from your explaination, a job was cancled (tripple check that it is gone) and the queue is still open for input, messages are indoubt, and you still see the job as an active thread, but there is no indoubt thread.
This is an error situation. MQ should cleanup when the job was cancled. MQ did not. So your MQ is in error. There is no command to fix that.
Take a dump and report the problem.
This was a batch job with only MQ involved? Or did it use something like RRS to coordinate with another subsystem?
What happens if you alter the queue get(disabled)? do the job goes away?
_________________
Regards, Butcher |
|
| Back to top |
|
|
| Ross |
| Posted: Fri Jan 12, 2007 7:52 am Post subject: |
|
|
Centurion
Joined: 15 Jun 2005
Posts: 127
Location: Ireland
|
I was under the impression I understood the questions!!
Yes - Job cancelled. I keep checking and can't find it.
Yes - I see IPPROCS of 1, and it is this job.
I tried the INDOUBT job as suggested earlier and got no INDOUBT threads.
I have been reluctant to report the issue as IBM support are also involved on the call.
I don't know exectly what the app is doing, except that the MQOPEN is a step, and that is failing.
I did disable get earlier and this did nothing.
An additional thing is that the queue had an Exlusive open and although we can change the queue def to remove this, the open thread will still have the Exclusive Open. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Fri Jan 12, 2007 8:02 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
well, i have no more ideas what to try to resolve that (except a restart).
is the sending application still putting messages to the queue? can you change the sending application to put to a different queue, and use that queue in your batch job so you can continue processing messages (of course you can not get your hands on the messages that are currently in the "stuck" queue)
whats the reson code that you get on the failing mqopen?
_________________
Regards, Butcher |
|
| Back to top |
|
|
| Ross |
| Posted: Fri Jan 12, 2007 8:11 am Post subject: |
|
|
Centurion
Joined: 15 Jun 2005
Posts: 127
Location: Ireland
|
The reason code is 2042.
It appears the thread started to disconnect, and started the backout, and has not been able to complete the backout.
This is an IMS BMP.
We are following up on ways to compplete the backout |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jan 12, 2007 8:24 am Post subject: |
|
|
Guest
|
Ah! It's an IMS-MQ application. You will need to work with your IMS support folks at some point.
mq command to display threads will show you what units of work remain in-flight. exactly what command did you use?
Did you restart mq? at mq restart, mq will tell you (on syslog) what threads are indoubt.
did you restart ims? at restart, ims will tell you what threads are indoubt.
once you discover the thread-id, you can do an mq RESOLVE command to complete the in-flight unit of work. There's an equivalent ims command to do the same thing from ims's side. |
|
| Back to top |
|
|
| Ross |
| Posted: Fri Jan 12, 2007 8:36 am Post subject: |
|
|
Centurion
Joined: 15 Jun 2005
Posts: 127
Location: Ireland
|
As this is 1 small application, we don't want to restart MQ or IMS.
There are no indoubt threads so can't resolve indoubt (I did try this).
Here is the display thread info:
NAME S T REQ THREAD-XREF USERID ASID URID
ECE0000A D*B 138 000000000000000000000000 UCC7 00A7 02A7DF549088 |
|
| Back to top |
|
|
| KevinF23492 |
| Posted: Fri Jan 12, 2007 9:48 am Post subject: |
|
|
Novice
Joined: 26 Dec 2006
Posts: 22
|
Aha....so IMS has it's grubby little mitts in the deal huh? Now that starts to make more sense.
Are you invoking the IMS Transaction from the batch job or is the batch job using a queue that is an IMS Bridge queue to kick the transaction off? |
|
| Back to top |
|
|
|
|
