| Author |
Message
|
| moonwalker |
 Posted: Fri Feb 20, 2015 5:27 pm Post subject: Execution group reporting MQRC 2082 MQRC_UNKNOWN_ALIAS_BASE_ |
 |
|
Apprentice
Joined: 02 Jun 2009
Posts: 42
|
Hello Everybody,
Here's the change we did recently, I am publishing the sequence of events.
1. We had a series of alias queue which were clustered. The base queue of these alias queues were remote definitions which remain on the same QM (QM.A) as the alias queues. The remote definitions pointed to a set of alias queues on a non clustered QM (say QM.B) and are pointing to local queues. This was the existing setup.
2. We had requirement to stop QM.A to reduce the number of hops. So we tried to accommodate the alias queues on an existing QM (say QM.C) and established communication via remote definitions to QM.B
3. The above change result in the following setup
a.An alias q (say AQ.1) on QM.C is now a local alias q while it was clustered in QM.A earlier
b. AQ.1 point to a remote definition queue (say RQ.1)
c. RQ.1 point to another alias q on QM.B
After this change was made we received the below error was logged in broker logs.
Feb 18 17:12:03 dwmb02 WebSphere Broker v8004[757]: (DEBK02.EG1)[8]BIP2623E: Unable to open queue 'AQ.1' on WebSphere MQ queue manager '': completion code 2; reason code 2082. : DEBK02.07062a87-4901-0000-0080-c7071fcba392: /build/slot1/S800_P/src/DataFlowEngine/ImbMqManager.cpp: 679: ImbMqConnection::getQueue: ComIbmMQConnectionManager: ComIbmMQConnectionManager
Please notice that the queue manager name is empty and shows ''. At flow we use MQOutput node which is set to use the destination list and QM name is allowed to be empty due to the use of alias queues.
Another weird behavior is this error is being reported by only one Execution group EG1 on broker DEBK02 while we have 6 more EG's which never reported any issue. One mistake we did was we did not try testing on the other EG's as similar instances of flows were running.
can this be an issue related to the unavailability of connection as we might have reached the max connections? The reason this comes to my mind is broker queue manager logs reports the following errors repeatedly even though they existed as expected.
"The remote system does not have sufficient resources to run another instance of the channel"
OR
"There is no definition of channel 'DBRK02.DB01' at the remote location"
Please share your thoughts and views regarding the same as we are very near to go live dates and this issue seems to a show stopper as I am running out of options.
Thanks in advance. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Sat Feb 21, 2015 6:21 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Well you are changing from a clustered setup to a non clustered setup.
A few differences here:
- If the queue the flow puts to is not a queue existing on the broker's queue manager you will have to add a destination qmgr to the MQOutput node setup, as well as a default route to said destination qmgr.
- Destinations that just "used to work" will no longer do so and require a default route
- qmgr alias or xmitq defined with the destination qmgr name
- explicitly defined sender channel to the destination qmgr or next hop
- review of authorizations needed. You may have to add some new ones.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| moonwalker |
| Posted: Thu Feb 26, 2015 10:08 am Post subject: |
|
|
Apprentice
Joined: 02 Jun 2009
Posts: 42
|
Below are the findings post testing
1. We were trying to use an alias queue which was once clustered.
2. The issue faced has nothing to do with alias queues
3. Issue was MQ was unable to resolve the queue manager name. why?
- what was once clustered is now unclustered
- We tried everything from refreshing the clusters to restarting QM
- Infact MQ services too was restarted
- Yet MQ looks for a clustered version of alias queue.
- As a final attempt I changed only the name of the alias q while the base queue configurations remained the same.
- Then started to work fine as expected
- So the problem was with the full repositories not refreshing the unclustered queues information. So changing the name did the trick.
Hope this info helps. thanks |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Feb 26, 2015 10:15 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| moonwalker wrote: |
Below are the findings post testing
1. We were trying to use an alias queue which was once clustered.
2. The issue faced has nothing to do with alias queues
3. Issue was MQ was unable to resolve the queue manager name. why?
- what was once clustered is now unclustered
- We tried everything from refreshing the clusters to restarting QM
- Infact MQ services too was restarted
- Yet MQ looks for a clustered version of alias queue.
- As a final attempt I changed only the name of the alias q while the base queue configurations remained the same.
- Then started to work fine as expected
- So the problem was with the full repositories not refreshing the unclustered queues information. So changing the name did the trick.
Hope this info helps. thanks |
If your full repositories are not refreshing the queue information, after you removed the queue from the cluster, you did something wrong (like removing the queue manager from the cluster before removing the queues from the cluster)... Mind you you would have to bounce the broker as it keeps the output queue open...
It is easier when the full repository is by itself and has no active queues in it. This also means no application will have any queue open on the FR so nothing is preventing you from propagating the change....
_________________
MQ & Broker admin
Last edited by fjb_saper on Fri Feb 27, 2015 10:17 am; edited 1 time in total |
|
| Back to top |
|
|
| moonwalker |
| Posted: Fri Feb 27, 2015 6:25 am Post subject: |
|
|
Apprentice
Joined: 02 Jun 2009
Posts: 42
|
| Yes one of the full repositories was taken out of the cluster. The queues on that cluster QM were recreated on a different clustered QM but as local queues as we learnt that there is no need to have those queues clustered. |
|
| Back to top |
|
|
|
|
