| Author |
Message
|
| mago |
 Posted: Fri Mar 14, 2025 8:34 am Post subject: Issue Deleting Queues with Uncommitted Messages |
 |
|
Newbie
Joined: 14 Mar 2025
Posts: 3
|
Hello, everyone.
We are experiencing an unusual behavior in our Mainframe environment (MQ 9.3). We're trying to delete two queues from the QSG that receive messages from a subscription, but we haven't been successful.
Each of these queues has 13 uncommitted messages. We've recycled all the Queue Managers and all the CICS regions, yet the problem persists, and we are still unable to delete the queues.
For both queues, we receive the same error (detailed below).
CSQM110I %QXXX CSQMUQLC QLOCAL(QE.XXX)
QSGDISP(SHARED) HAS INCOMPLETE UNITS OF RECOVERY
CSQM090E %QXXX CSQMUQLC FAILURE REASON CODE X'00D44005'
CSQ9023E %QXXX CSQMUQLC ' DELETE QLOCAL' ABNORMAL COMPLETION
Has anyone encountered a similar issue or has any suggestions on how to resolve this? We need to delete these queues and redefine them as local queues, but we haven't been able to do so.
Thank you in advance for your help! |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Fri Mar 14, 2025 12:11 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Have you tried looking at orphaned units of work and either committing them or rolling them back?
After you have done this the uncommitted messages should be gone, and you should be able to delete the queues. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Mar 14, 2025 12:34 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
|
| Back to top |
|
|
| mago |
| Posted: Tue Apr 01, 2025 2:20 pm Post subject: |
|
|
Newbie
Joined: 14 Mar 2025
Posts: 3
|
| Hello, everyone. Just an update on the issue: it was only resolved when we canceled the MQ task, instead of stopping it normally or using force. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Apr 01, 2025 3:44 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| mago wrote: |
| Hello, everyone. Just an update on the issue: it was only resolved when we canceled the MQ task, instead of stopping it normally or using force. |
Please be precise. Which MQ task did you cancel? Do you mean you cancelled the MQ address space? If not, what was the name of the task you cancelled? How did you cancel the task?
_________________
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 |
|
|
| mago |
| Posted: Wed Apr 02, 2025 4:52 am Post subject: |
|
|
Newbie
Joined: 14 Mar 2025
Posts: 3
|
| Sorry for the lack of clarity. We cancel the MSTR address space. |
|
| Back to top |
|
|
| mago |
| Posted: Wed Apr 02, 2025 5:42 am Post subject: |
|
|
Newbie
Joined: 14 Mar 2025
Posts: 3
|
Message from IBM:
While all the structures are connected, issue a Cancel against Q1MSTR.
This should result in the other members being notified of the failed qmgr and attempting Peer-Level Recovery.
Last edited by mago on Wed Apr 02, 2025 7:05 am; edited 1 time in total |
|
| Back to top |
|
|
| mago |
| Posted: Wed Apr 02, 2025 5:48 am Post subject: |
|
|
Newbie
Joined: 14 Mar 2025
Posts: 3
|
Message from IBM:
There are a couple of phases to the processing.
The recovering qmgr uses information in the admin structure to determine the status of any transactions which were in the process of being committed on the failed qmgr. The admin structure entries provide information about the messages involved in the transaction and how far it progressed. Any changes required to complete or back out the transaction are performed.
Once the first phases is complete, the application structures are scanned for any messages that are marked as uncommitted by the failed qmgr. If they are still in an uncommitted state after phase 1 then they must have been part of an in-flight transaction and will be backed out.
 |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Apr 02, 2025 7:07 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| mago wrote: |
Hello, everyone.
In this same scenario we have a topic on MQ z/OS with high message traffic (millions per day).
|
Millions of messages per second would be high message traffic on z/OS
| mago wrote: |
| There are also 30 subscriptions pointing to different queues. |
Are the 30 subscriptions in a single application?
| mago wrote: |
The application is experiencing very high latency at the time of the PUT.
|
How do you know that the app is experiencing very high latency at the time of the PUT?
Does the app do database SQL calls?
Is this a new app? An existing app with recent changes?
| mago wrote: |
Is there any IBM document with configuration and tuning recommendations for TOPICs and SUBSCRIPTIONS? I haven?t found anything so far (for example, there?s nothing in MP16: IBM MQ for z/OS - Capacity planning & tuning).
-- |
_________________
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 |
|
|
|
|
