| Author |
Message
|
| nagireddy |
 Posted: Tue May 05, 2015 12:45 am Post subject: permanent dynamic cluster transmission queue damage |
 |
|
Newbie
Joined: 15 May 2014
Posts: 2
|
Hello,
Is there any way to recover the permanent dynamic cluster transmission queue (SYSTEM.CLUSTER.TRANSMIT.**) in Liner Logging mechanism. If yes, can you please advice me. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue May 05, 2015 4:49 am Post subject: Re: permanent dynamic cluster transmission queue damage |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| nagireddy wrote: |
| Is there any way to recover the permanent dynamic cluster transmission queue (SYSTEM.CLUSTER.TRANSMIT.**) in Liner Logging mechanism. If yes, can you please advice me. |
The same way you'd recover any other queue using linear logging. While it's used internally by the system, from a logging point of view it's just a queue. Clearly relies on your linear logging strategy (object recording and so forth) catering for that queue / those queues in the same way as it has to cater correctly for a permanent queue & it's contents. But not more so.
Depending on what's caused you to need to recover it, you might need to take some minor remedial action within the cluster. Or not.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue May 05, 2015 7:05 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Well it all depends on how it came to be missing...
If it was a consequence of a delete queue command, then no, linear logging will not help you recover from such a mistake.
There are however ways to start a queue manager that have it recreate system objects...
If it was a consequence of a file having been deleted, or just plain a damaged object, then yes linear logging should allow you to recover the object. Read up on rcvrmqobj....
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| nagireddy |
| Posted: Thu May 07, 2015 11:05 pm Post subject: Re: permanent dynamic cluster transmission queue damage |
|
|
Newbie
Joined: 15 May 2014
Posts: 2
|
The system cluster dynamic queue (SYSTEM.CLUSTER.TRANSMIT.TO.**) ghost file !!GHOST!D4BA552C!0!174E391F!3 was damaged, when the system admin did some N A S level changes (i think he removed some N A S snapshot).
So application started facing 2101 (MQRC_OBJECT_DAMAGED), how to get it recreated the system cluster dynamic queues??
I have performed the below steps, none of them helped..
#1. tried to delete the queue physical definition, its failed with MQRC_OBJECT_DAMAGED.
#2. recreated the same queue name with replace object, its successed, But app is facing the same issues after i created the queue..
#3. then i did endmqm -i QMGR ==> strmqm -c QMGR ==> strmqm QMGR
Still the issues is persist, how to get this issues addressed. Do you have any suggestions please.. Much thanks for your help! |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri May 08, 2015 4:12 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Have you tried recovering the model queue on which the dynamic queues for your CTQ rely on?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Andyh |
| Posted: Fri May 08, 2015 5:02 am Post subject: |
|
|
Master
Joined: 29 Jul 2010
Posts: 239
|
It should be possible to delete a damaged object.
If you are unable to delete a damaged object you should open a PMR.
If you're using linear logging then you should be able to recover the object.
If you're using circular logging it should be possible to delete (and redefine (if appropriate)) the object.
Performing a define+replace for a damaged object will not recover that object.
Deleting/Redefining/Recovering a model queue will not recover a dynamic queue created from that model. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri May 08, 2015 5:27 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Andyh wrote: |
It should be possible to delete a damaged object.
If you are unable to delete a damaged object you should open a PMR.
If you're using linear logging then you should be able to recover the object.
If you're using circular logging it should be possible to delete (and redefine (if appropriate)) the object.
Performing a define+replace for a damaged object will not recover that object.
Deleting/Redefining/Recovering a model queue will not recover a dynamic queue created from that model. |
@Andyh The point here was that it was not the dynamic queue that got damaged, but the corresponding ghost pool. And that said ghost pool stayed damaged after recycling the queue manager... Hence the idea to look at the model queue...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Andyh |
| Posted: Fri May 08, 2015 8:50 am Post subject: |
|
|
Master
Joined: 29 Jul 2010
Posts: 239
|
A ghost pool is a collection of UNUSED ghost queues, and is NOT the subject of the damage.
The queue file for a dynamic queue has a file name starting with a !!GHOST! prefix, and as healthy dynamic queues are deleted and recreated these file system objects are re-used, thus improving the efficiency of creating and deleting dynamic queues.
When the file system object (the !!GHOST!... file) associated with a dynamic queue becomes corrupted that queue is flagged as damaged and must be recovered in the same way as any other queue.
No direct action against the !!GHOST!... file should be undertaken, the object should be referred to by the queue name of the dynamic queue currently associated with that file system object.
It SHOULD be possible to delete this queue with a runmqsc DELETE QL command, or (in the case of linear logging) to recreate the queue with the rcrmqobj command.
Multiple cluster transmit queues are relatively new (7.5) and as you might expect there's some special treatment for these queues inside the queue manager. It's not beyond the realms of possibility that some internal handle to the queue would be preventing the queue from being deleted (that would imply an APARable bug).
If that was the case it would be likely that attempting to delete the queue after the restart (the thread mentions a restart has already been performed) would succeed. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri May 08, 2015 12:40 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
I was thinking that in order to be able to delete the queue you first had to change the configuration so that the channel in question would not require a dynamic xmtq.
Once the queue was deleted you could restore the config for a dynamic xmtiq.
Not to forget to move messages slotted for that channel from the standard queue to the new dynamic xmitq or they might be stuck on the SCTQ right?
So the best bet in linear logging as you say is to recover the queue...
Thanks for your insight.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri May 08, 2015 12:48 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| I'm confused about discussions of SYSTEM.CLUSTER.TRANSMIT.QUEUE being a model queue... |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri May 08, 2015 1:08 pm Post subject: Re: permanent dynamic cluster transmission queue damage |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| nagireddy wrote: |
Hello,
Is there any way to recover the permanent dynamic cluster transmission queue (SYSTEM.CLUSTER.TRANSMIT.**) in Liner Logging mechanism. If yes, can you please advice me. |
Firstly, SYSTEM.CLUSTER.TRANSMIT.** is not a valid object name. This looks more like a RACF rule to secure a alternate SYSTEM.CLUSTER.TRANSMIT queue.
Did you alter the qmgr attribute so that each CLUSSDR channels would use a unique SCTQ? Or did you specify a specific SCQT for the channel in question?
What channel was the alternate transmission queue defined to? The resulting transmit queue would usually be suffixed with a dot and the channel name.
What o/s? What version of MQ?
_________________
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 |
|
|
| fjb_saper |
| Posted: Fri May 08, 2015 10:48 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| mqjeff wrote: |
| I'm confused about discussions of SYSTEM.CLUSTER.TRANSMIT.QUEUE being a model queue... |
Think SYSTEM.CLUSTER.TRANSMIT.MODEL.QUEUE...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat May 09, 2015 5:04 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon May 11, 2015 4:27 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I hadn't thought there was an option to automatically create a transmit queue for each cluster channel. I thought one had to do it manually.
Of course, I haven't configured a "real" cluster (outside of development environment) since v7.0 or so. |
|
| Back to top |
|
|
|
|
