| Author |
Message
|
| skrv |
 Posted: Mon Dec 01, 2014 10:38 am Post subject: AMQ8077: Entity 'xxx' has insufficient authority to acces |
 |
|
Centurion
Joined: 26 Oct 2012
Posts: 118
|
Hi,
We have 2 full repositories A and B and a partial repository C.
We have several clusters which were added to Namelist and used in channel definition betwee Full repos and between full & partial repos qmgrs.
recently we have added a new cluster name to Repos Cluster Namelist on both full repos and also to Namelist on partial repos qmgrs. We also defined new cluster channels between both full repos qmgrs and also added MCAUSER on CLUSRCVR channels.
So from partial repos qmgr C we have one set of channels to one full repos qmgr and cluster namelist has several clusterr names. among several clusters we have only one cluster for which we have added MCAUSER. So from partial repos qmgr cluster ABC has to use its own cluster channel to communicate with full reos qmgrs and which doesn't have MCAUSER in channel def and cluster XYZ should only use its cluster channel which has MCAUSER in its chnnel def.
But what we are seeing is for some of the communication(not all) cluster ABC is using cluster XYZ channel (which has MCAUSER) and messages are landing in dead letter queue because of non authority because MCAUSER won't be having access to clutser ABC objects, which is correct.
We don't know why ABC cluster is using XYZ cluster channel some times and hence messages landing in dead queue.
below is what we see in qmgr qrror log
-------------------------------------------------------------------
----- amqrmrca.c : 1569 -------------------------------------------------------
12/01/2014 12:38:03 PM - Process(300.28495) User(mqm) Program(amqzlaa0)
Host(xxxxx) Installation(Installation1)
VRMF(7.5.0.3) QMgr(xxxxx)
AMQ8077: Entity 'xxxxx ' has insufficient authority to access object
'XXX.GEN.XXXX.DQB.REPLY'.
EXPLANATION:
The specified entity is not authorized to access the required object. The
following requested permissions are unauthorized: put/setall
ACTION:
Ensure that the correct level of authority has been set for this entity against
the required object, or ensure that the entity is a member of a privileged
group.
----- amqzfubx.c : 624 --------------------------------------------------------
12/01/2014 12:38:04 PM - Process(4985.36277) User(mqm) Program(amqrmppa)
Host(xxxxxx) Installation(Installation1)
VRMF(7.5.0.3) QMgr(xxxxxxxx)
AMQ9544: Messages not put to destination queue.
EXPLANATION:
During the processing of channel 'TO.xxxxxxxxx.CDS.xxx' one or more messages
could not be put to the destination queue and attempts were made to put them to
a dead-letter queue. The location of the queue is 1, where 1 is the local
dead-letter queue and 2 is the remote dead-letter queue.
ACTION:
Examine the contents of the dead-letter queue. Each message is contained in a
structure that describes why the message was put to the queue, and to where it
was originally addressed. Also look at previous error messages to see if the
attempt to put messages to a dead-letter queue failed. The program identifier
(PID) of the processing program was '4985'. |
|
| Back to top |
|
 |
| JosephGramig |
| Posted: Mon Dec 01, 2014 11:36 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1231
Location: Gold Coast of Florida, USA
|
NAMELISTs and cluster channels are trouble.
Name the channel <cluster>.<Qmgr> but of course, that has to be less than 20 characters. This will ensure a unique pairing of cluster channels for one and only one cluster. If you do it this way, you will not find yourself with this problem.
Looks like you have multiple cluster receiver channels for a cluster and that will cause the msgs to be load balanced over those channels (even if they go to the same Qmgr). |
|
| Back to top |
|
|
| skrv |
| Posted: Mon Dec 01, 2014 12:52 pm Post subject: |
|
|
Centurion
Joined: 26 Oct 2012
Posts: 118
|
we have only one set of CLUSSDR/CLUSRCVR channels between partial repos and full repos qmgr. Between 2 full repos qmgrs we have 2 sets of CLUSSDR/CLUSRCVR channels. one set doesn't have MCAUSER and 2nd set has MCAUSER in them.
So when partial qmgr try to communicate with full repos qmgr it will use already existing channel to send data but if try to communicate with new channel(which is dynamic) it should get that definition from clusrcvr channel of full repos qmgr.
but here whats happening is even though we have one set of channel between partial and full repos qmgrs, we are seeing that for some communication it is trying to use MCAUSER channel for other cluster objects and throwing 2035 |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Mon Dec 01, 2014 1:19 pm Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1231
Location: Gold Coast of Florida, USA
|
On the two FRs with two cluster receiver channels if the two receiver channels (on one FR) reference the same cluster as what the PR also references, the PR most certainly will build two sender channels and load balance traffic between them.
BTW, it is always a good idea to put an ID in the MCAUSER for all inbound MCA (non-SVRCONN) channels that has less than mqm authority. If MCAUSER is blank, it will use the ID that is running the channel and that tends to be the service ID of the Qmgr. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Dec 01, 2014 1:23 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
To be slightly more clear.
You should probably redo your cluster topology to remove any use of CLUSNL, and replace it with specifically designated sets of channels that have only CLUSTER specified, and likewise share all objects using CLUSTER and not CLUSNL. |
|
| Back to top |
|
|
| skrv |
| Posted: Mon Dec 01, 2014 5:33 pm Post subject: |
|
|
Centurion
Joined: 26 Oct 2012
Posts: 118
|
redoing cluster topology is not option as we have this setup for more than 8 yrs and have 40+ clusters in that CLUSNL.
what should i do here to address the issue? should we take out second set of cluster channels (one with mcauser) between 2 FRs? |
|
| Back to top |
|
|
| rammer |
| Posted: Mon Dec 01, 2014 6:04 pm Post subject: |
|
|
Partisan
Joined: 02 May 2002
Posts: 359
Location: England
|
What output do you get if you run dis clusqmgr qmtype, to ensure that your queue managers are in the correct cluster?
Ive not really ever had issues with namelists for clusters being used and some acocunts I support have upto 15 different clusters. Only time I have seen problems is when someone had made a mistake themselves by putting a queue into the wrong cluster etc. |
|
| Back to top |
|
|
| skrv |
| Posted: Mon Dec 01, 2014 7:21 pm Post subject: |
|
|
Centurion
Joined: 26 Oct 2012
Posts: 118
|
that command gives me correct output, no issues there.
the issue is with usage of wrong channel by clusters (some time only) |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Dec 02, 2014 2:45 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
Remove the new cluster (with mcauser) from the clusnl.
Make sure all queue managers in the cluster (PR or FR) communicating have their own channel and do not share any with the namelist.
The same way (if you need to) create clustered aliases for the new cluster for queues that otherwise have a namelist on them. The reason here is that you need to make the routing choice distinct by removing any other possibilities but the one you desire... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Tue Dec 02, 2014 6:14 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1231
Location: Gold Coast of Florida, USA
|
| skrv wrote: |
| What should i do here to address the issue? should we take out second set of cluster channels (one with mcauser) between 2 FRs? |
Yes.
Ensure that you do not have more than one cluster receiver for any cluster membership at each Qmgr.
What was your intent by adding the MCAUSER on the channel? |
|
| Back to top |
|
|
|
|
