| Author |
Message
|
| w33f |
 Posted: Thu Nov 07, 2013 10:12 pm Post subject: Clustering error - channel in RETRYING getting 2085 |
 |
|
Novice
Joined: 07 Nov 2013
Posts: 17
|
Hi guys
So I have a weird problem.. I've got a partial repository which I'm joining into a cluster. Everything looks good after joining, I can see the first full repository and other qmgrs are in a RUNNING state, but for some reason the CLUSSDRA channel to the 2nd Full repository of the cluster is in a RETRYING state with the following error in the logs:
| Code: |
-------------------------------------------------------------------------------
08/11/13 12:02:03 - Process(29069.7287) User(mqm) Program(amqrmppa)
AMQ9509: Program cannot open queue manager object.
EXPLANATION:
The attempt to open either the queue or queue manager object 'SCTQ.CLUSTER_NAME.01'
on queue manager 'LOCAL_QM' failed with reason code 2085.
ACTION:
Ensure that the queue is available and retry the operation.
----- amqrmssa.c : 676 --------------------------------------------------------
08/11/13 12:02:03 - Process(29069.7287) User(mqm) Program(amqrmppa)
AMQ9999: Channel program ended abnormally.
EXPLANATION:
Channel program 'TO.FULL_REPOS2.CLUSTER_NAME' ended abnormally.
ACTION:
Look at previous error messages for channel program 'TO.FULL_REPOS2.CLUSTER_NAME' in
the error files to determine the cause of the failure.
----- amqrccca.c : 834 -------------------------------------------------------- |
Apparently SCTQ.CLUSTER_NAME.01 is the name of the system cluster transmit queue being used from Full Repos 1 to Full Repos 2. I don't manage those Full Repos servers so It's a bit hard for me to get info on them. My QM version is 6, the Full Repos's are using MQ 7.5 with channel auth records.
Just curious if anyone's experienced this before or has any advice? |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Sat Nov 09, 2013 1:54 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
It's a bit tricky when you're not using the default SCTQ.
Obviously some rule was set up in the FR's to use a specific CTQ.
Before the channel can work the admin needs to make sure that the corresponding CTQ will exist!
It appears to me the 2085 is your return code because the name of the CTQ as derived by the rule does not match any existing CTQ.
Create the corresponding CTQ on the FR and see if messages start to flow.
I'd say it's a case of shooting yourself in the foot! 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| w33f |
| Posted: Sun Nov 10, 2013 7:29 pm Post subject: |
|
|
Novice
Joined: 07 Nov 2013
Posts: 17
|
Yo, thanks for the reply.
I guess what I'm confused about is why is my qmgr, a partial repository, getting 2085 errors saying it can't find a particular SCTQ which is being used on the FR? My qmgr should only be using the default SYSTEM.CLUSTER.TRANSMIT.QUEUE for all CLUSSDR channels, however something is telling it to use the same definitions as is on the FR.
Just curious if this is a known issue between MQ 7.5 and and 6, or whether there's some particular attribute (eg. CLCHNAME) being set on the FR's cluster queue which may be causing this to happen. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Nov 10, 2013 10:47 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
AFAIK a specific CTQ is a 7 attribute. However the channel definition V7 receive from the FR might request the specific CTQ defined on V7. Have no idea how V6 will handle this... but apparently it will require you to create the CTQ like you had to on V7. Whether it will then pick up msgs there ??? Maybe define it as alias to SCTQ?
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Nov 11, 2013 4:51 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
I agree with you w33f that this seems wrong. The attribute to tell a CLUSSNDR channel to use a transmit queue other than the default SYSTEM.CLUSTER.TRANSMIT.QUEUE is the DEFCLXQ attribute of the queue manager, or the CLCHNAME attribute of a local queue that has a Usage of XMITQ. In both cases these are only available on the version 7.5 Queue Manager, and since its not an attribute of the CLUSRCVR channel, I don't understand how / why an auto defined CLUSSNDR channel on another Queue Manager based off that CLUSRCVR would be looking for this, especially a queue manager running at an MQ version prior to 7.5.
To clarify, that MQ error log snippet you posted is from your version 6 partial repository queue manager named "LOCAL_QM"? If yes, I think this might be worth opening a PMR on.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| w33f |
| Posted: Mon Nov 11, 2013 2:50 pm Post subject: |
|
|
Novice
Joined: 07 Nov 2013
Posts: 17
|
| Correct Pete, that's the log from my v6 qmgr. I have the PMR page open now.. I'll update you guys if I make any progress. |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Tue Nov 12, 2013 6:13 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1230
Location: Gold Coast of Florida, USA
|
| Unless you have extended support, IBM Support is going to tell you to migrate that V6 Qmgr.... |
|
| Back to top |
|
|
| AniDeshpande |
| Posted: Sun Mar 16, 2014 8:42 pm Post subject: |
|
|
Newbie
Joined: 16 Mar 2014
Posts: 2
|
Hi,
I am facing a similar issue, trying to join a MQ 7.1 Queue Manager to a MQ 7.5 Full Repository. w33f, did you happen to fix the issue at all ?
Please let me know.
Thanx
Ani |
|
| Back to top |
|
|
| AniDeshpande |
| Posted: Tue Apr 08, 2014 4:59 pm Post subject: |
|
|
Newbie
Joined: 16 Mar 2014
Posts: 2
|
Hi,
Just to update everyone here, raised a PMR with IBM and looks like it a BUG, there is a temporary fix available for it. However, it will be available with FP 7.5.04 available in Q3.
Thanks |
|
| Back to top |
|
|
| rammer |
| Posted: Wed Apr 09, 2014 8:55 am Post subject: |
|
|
Partisan
Joined: 02 May 2002
Posts: 359
Location: England
|
| AniDeshpande wrote: |
Hi,
Just to update everyone here, raised a PMR with IBM and looks like it a BUG, there is a temporary fix available for it. However, it will be available with FP 7.5.04 available in Q3.
Thanks |
Hi did IBM provide you any link to temporary fix, I have similar issue. PMR raised yesterday, and wouldnt mind taking a look at it.
Version 7.5 queue manager to queue manager is fine or even 7.5 to 6 is fine. Issue is 6.x to 7.5 I get similar error.
Strangely though it works fine in other environments with exactly same set up and same version of queue managers.
Thanks |
|
| Back to top |
|
|
| rammer |
| Posted: Thu Apr 10, 2014 5:21 pm Post subject: |
|
|
Partisan
Joined: 02 May 2002
Posts: 359
Location: England
|
| rammer wrote: |
| AniDeshpande wrote: |
Hi,
Just to update everyone here, raised a PMR with IBM and looks like it a BUG, there is a temporary fix available for it. However, it will be available with FP 7.5.04 available in Q3.
Thanks |
Hi did IBM provide you any link to temporary fix, I have similar issue. PMR raised yesterday, and wouldnt mind taking a look at it.
Version 7.5 queue manager to queue manager is fine or even 7.5 to 6 is fine. Issue is 6.x to 7.5 I get similar error.
Strangely though it works fine in other environments with exactly same set up and same version of queue managers.
Thanks |
I fixed my issue,
The problem I had was V6 to V7.5 Qmgr using clustering.
The 7.5 is a PR. My FR is also 7.5.
On the FR I had a dedicated XMITQ being used instead of SCTQ to the 7.5 PR and this was named with the same name as the target qmgr.
As this was a new environment and not currently in full service I rebuild the FR and 7.5 PR using the backups but removed the XMITQ and stuck with SCTQ.
Version 6 is now working fine to 7.5. |
|
| Back to top |
|
|
|
|
