ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » General Discussion » MQRC 2035 for backout queue.

Post new topic  Reply to topic
 MQRC 2035 for backout queue. « View previous topic :: View next topic » 
Author Message
MQMB&WAS
PostPosted: Wed May 27, 2020 12:27 am    Post subject: MQRC 2035 for backout queue. Reply with quote

Centurion

Joined: 12 Jun 2016
Posts: 130

Hello experts,

There's a backout queue configured for an application queue and the application ID has get, put, browse, inq permissions to this backout queue.

The issue is, I see messages that are supposed to go to this backout queue are landing in the dead queue with mqrc 2035. However, when I replay the messages in this dead queue, they are processed fine and lands in the actual backout queue. This has been happening repeatedly.

What could be the issue?

MQRC 2035
destination queue: backout queue name

Appreciate your time.
Back to top
View user's profile Send private message
exerk
PostPosted: Wed May 27, 2020 2:54 am    Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

Questions:

1. Under which userid are you replaying the messages from the DLQ to the back-out queue?

2. Are you certain the application is trying to put messages to the back-out queue using its userid, i.e. it could be using a contextual userid?

3. What do the queue manager logs show when it happens as usually the 'offending' userid is shown, along with the 'missing' authority?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Wed May 27, 2020 4:59 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY

I guess you are missing the INQ permission on the backout queue.
If the application is JMS the inq persmission is needed.
As my esteemed colleague pointed out, the queue manager logs should show you precisely which permission is missing
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
exerk
PostPosted: Wed May 27, 2020 5:59 am    Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

fjb_saper wrote:
I guess you are missing the INQ permission on the backout queue...

MQMB&WAS wrote "...application ID has get, put, browse, inq permissions to this backout queue..."

fjb_saper wrote:
...As my esteemed colleague pointed out...

Bearing in mind your reputation, I am honoured, thank you.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.
Back to top
View user's profile Send private message
Vitor
PostPosted: Wed May 27, 2020 6:06 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

exerk wrote:
fjb_saper wrote:
...As my esteemed colleague pointed out...

Bearing in mind your reputation, I am honoured, thank you.


Get back in the dungeon and social distance from your self esteem


_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
exerk
PostPosted: Wed May 27, 2020 6:12 am    Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

Vitor wrote:
exerk wrote:
fjb_saper wrote:
...As my esteemed colleague pointed out...

Bearing in mind your reputation, I am honoured, thank you.


Get back in the dungeon and social distance from your self esteem


What self esteem? You (very surgically) removed that from me a long time ago!
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.
Back to top
View user's profile Send private message
Vitor
PostPosted: Wed May 27, 2020 6:25 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

exerk wrote:
What self esteem? You (very surgically) removed that from me a long time ago!


And I keep it in a jar in my laboratory so I can laugh at it when I need cheering up.

So I don't want you getting to friendly with it.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
hughson
PostPosted: Wed May 27, 2020 8:41 pm    Post subject: Re: MQRC 2035 for backout queue. Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand

MQMB&WAS wrote:
There's a backout queue configured for an application queue and the application ID has get, put, browse, inq permissions to this backout queue.

The issue is, I see messages that are supposed to go to this backout queue are landing in the dead queue with mqrc 2035. However, when I replay the messages in this dead queue, they are processed fine and lands in the actual backout queue. This has been happening repeatedly.


Your queue manager AMQERR01.LOG should have a message that explains what authority was missing to cause the 2035 reason code. It will look something like this:-

Code:
AMQ8077W: Entity 'mqgemusr' has insufficient authority to access object 'MY.BACKOUT.QNAME'.

EXPLANATION:
The specified entity is not authorized to access the required object. The
following requested permissions are unauthorized: passall


You might see this for the application queue (missing +inq in order to even obtain the name of the backout queue), or you might see this for the backout queue, which will again tell you what is missing. The fact that the Dead-Lettered message contains the name of the backout queue suggests it is the latter of course.

The fact that it works when you replay it from the Dead-Letter Queue suggests that the Dead-Letter Handler has a greater level of authority than the application.

Thinking about what you might be missing (given that we haven't seen what your error log is telling you), I guess it might be something like 'passall' since you normally would MQPMO_PASS_ALL_CONTEXT when you move a poison message from an application queue to a backout queue in order to retain all the information about the original putter for analysis later.

Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software
Back to top
View user's profile Send private message Visit poster's website
fjb_saper
PostPosted: Thu May 28, 2020 10:49 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY

And in order to use passall on the queue, I believe you also need passall on the qmgr...
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
MQMB&WAS
PostPosted: Fri May 29, 2020 12:42 am    Post subject: Re: MQRC 2035 for backout queue. Reply with quote

Centurion

Joined: 12 Jun 2016
Posts: 130

hughson wrote:


Thinking about what you might be missing (given that we haven't seen what your error log is telling you), I guess it might be something like 'passall' since you normally would MQPMO_PASS_ALL_CONTEXT when you move a poison message from an application queue to a backout queue in order to retain all the information about the original putter for analysis later.

Cheers,
Morag


Yes, passall was missing. Thanks Morag.
Back to top
View user's profile Send private message
MQMB&WAS
PostPosted: Fri May 29, 2020 12:45 am    Post subject: Reply with quote

Centurion

Joined: 12 Jun 2016
Posts: 130

fjb_saper wrote:
And in order to use passall on the queue, I believe you also need passall on the qmgr...


The ID has only inq and connect permissions to the qmgr, and with inq, browse, put, get, passall permissions to the queue, messages are not landing in the dlq.

Thanks everyone.
Back to top
View user's profile Send private message
MQMB&WAS
PostPosted: Fri May 29, 2020 12:47 am    Post subject: Reply with quote

Centurion

Joined: 12 Jun 2016
Posts: 130

One more question, when we give permissions to an app, should we do it user id (-p) or group id (-g) ? Both seems to work fine.
Back to top
View user's profile Send private message
hughson
PostPosted: Fri May 29, 2020 2:34 am    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand

MQMB&WAS wrote:
One more question, when we give permissions to an app, should we do it user id (-p) or group id (-g) ? Both seems to work fine.

Both will work, but best practice is to use groups.

Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software
Back to top
View user's profile Send private message Visit poster's website
MQMB&WAS
PostPosted: Tue Jun 02, 2020 9:35 pm    Post subject: Reply with quote

Centurion

Joined: 12 Jun 2016
Posts: 130

hughson wrote:
MQMB&WAS wrote:
One more question, when we give permissions to an app, should we do it user id (-p) or group id (-g) ? Both seems to work fine.

Both will work, but best practice is to use groups.

Cheers,
Morag


Thanks Morag
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » General Discussion » MQRC 2035 for backout queue.
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.