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 IBM MQ Support » 2035 with server bindings

Post new topic  Reply to topic
 2035 with server bindings « View previous topic :: View next topic » 
Author Message
csaunders
PostPosted: Thu Mar 27, 2003 1:03 pm    Post subject: 2035 with server bindings Reply with quote

Acolyte

Joined: 27 Mar 2003
Posts: 64
Location: Arlington, Va

We have multiple applications accessing a qmanager. One of these applications when using jms server bindiing gets 2035, if we switch to client bindings the 203 goes away. The applications are written in java and are using weblogic 6.1 as the apps server. Any sugestions?
Back to top
View user's profile Send private message AIM Address
bduncan
PostPosted: Thu Mar 27, 2003 2:07 pm    Post subject: Reply with quote

Padawan

Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley

This is a common problem, you might want to try using the search tool and looking for "2035" or "dspmqaut".
You should first use dspmqaut to see if the user that the application is running as has access to the queue manager/queue in question. And if you have used setmqaut to change permissions recently you may need to issue "REFRESH SECURITY" from runmqsc if you are using MQ5.3, otherwise restart the queue manager.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator
Back to top
View user's profile Send private message Visit poster's website AIM Address
csaunders
PostPosted: Wed Apr 02, 2003 7:52 am    Post subject: Reply with quote

Acolyte

Joined: 27 Mar 2003
Posts: 64
Location: Arlington, Va

All of the setmqaut have been made for the q's, the qmanger objects, and the qmanager itself. Another applciation on the box connects to the same qmanager the exact same way and they dont get the exception "2035".
Refresh security has been run many times. A little more info, were running on Sun Solaris 8, the applications owner weblogic is part of the group mquser(which we created for mq). I ran the truss command against weblogic,
but I having a hard time understanding the truss contents.

truss -aelfd -u a.out -u "libmq*::" -u "libc::get*" -u "libc_r::get*" -o
(SOME OUTPUT FILE) -p (PID for the WebLogic Java process)

2831/293: 334.9635 -> libmqmcs:InitProcessVars(0xff0218, 0x0, 0xffffffff, 0xa4f5c190)
2831/293: 335.1722 -> libc:getuid(0x0, 0x0, 0x0, 0x0)
2831/293: 335.2045 getuid() = 4030 [4030]
2831/293: 335.2355 <- libc:getuid() = 4030
2831/293: 335.2585 -> libmqmcs:xcsGetpwuid(0xfbe, 0xa4dfec4c, 0xa4dfdf28, 0xd23)
2831/293: 335.2780 -> libc:getpwuid_r(0xfbe, 0xa4dfec4c, 0xa4dfdf28, 0xd23)
2831/293: 335.2943 open64("/etc/.name_service_door", O_RDONLY) = 304
2831/293: 335.3118 fcntl(304, F_SETFD, 0x00000001) = 0
2831/293: 335.3407 door_info(304, 0xFF342720) Err#9 EBADF
2831/293: 335.3704 close(304) = 0
2831/293: 335.4006 -> libc:getiop(0xff34027c, 0xff340414, 0xff340460, 0xecff68)
2831/293: 335.4223 <- libc:getiop() = 0
2831/293: 335.4411 -> libc:getiop(0xff34028c, 0xff340414, 0xff340414, 0x0)
2831/293: 335.4624 <- libc:getiop() = 0
2831/293: 335.4794 -> libc:getiop(0xff34029c, 0xff340414, 0xff340414, 0x0)
2831/293: 335.5107 <- libc:getiop() = 0
2831/293: 335.5456 -> libc:getiop(0xff3402ac, 0xff340414, 0xff340414, 0x0)
2831/293: 335.5792 <- libc:getiop() = 0xff3402ac
2831/293: 335.6144 open("/etc/passwd", O_RDONLY) = 304
2831/293: 335.6451 close(304) = 0
2831/293: 335.6762 <- libc:getpwuid_r() = 0
2831/293: 335.7094 <- libmqmcs:xcsGetpwuid() = 24
2831/293: 335.7271 <- libmqmcs:InitProcessVars() = 0
2831/293: 335.7459 <- libmqmcs:InitPrivateServices() = 0
Back to top
View user's profile Send private message AIM Address
gward123
PostPosted: Fri Apr 04, 2003 10:36 am    Post subject: Reply with quote

Novice

Joined: 27 Mar 2003
Posts: 11
Location: Roseland, NJ

The only thing that comes to mind for the troubled app is that the channel used when connecting via the client has MCAUSER hardcoded to give sufficient privileges or the client app is running under a different userid than the "server" bindings app (which would use the app servers id)?
_________________
Gary J. Ward
Sr. Technical Consultant
ADP
Back to top
View user's profile Send private message Send e-mail
meekings
PostPosted: Fri Apr 04, 2003 10:59 am    Post subject: Reply with quote

Voyager

Joined: 28 Jun 2001
Posts: 86
Location: UK, South West

As well as +get, +put and +browse, a JMS app needs +inq, which a regular app usually doesn't need (unless it opens for inquire). Check the authorizations for the user you're running as. Definitely as a client (unless you supply a username in your app or via MCAUSER), the app will be running with full privileges, so you won't encounter authorization problems.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
csaunders
PostPosted: Fri Apr 04, 2003 12:54 pm    Post subject: Reply with quote

Acolyte

Joined: 27 Mar 2003
Posts: 64
Location: Arlington, Va

both apps(troubled and working) are running as the same user. This is a clustered environment. Im starting to think its a SUN issue...... maybe this error is eroneous
Back to top
View user's profile Send private message AIM Address
meekings
PostPosted: Fri Apr 04, 2003 1:15 pm    Post subject: Reply with quote

Voyager

Joined: 28 Jun 2001
Posts: 86
Location: UK, South West

As a Java client, unless you're setting your user name in the app or in the MCAUSER channel parameter, the channel agent is running as mqm, regardless of the user you're starting the app up as, so it will have no authorization issues. In bindings mode, you're running under your own user name, and you may.
Check that your username has +connect and +inq on the QM, and +get, +put, +browse, +dsp and +inq on the queues (JMS has no concept of open for read, open for write, so opens for both).
_________________
Brian Meekings
Information Design, Inc.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
csaunders
PostPosted: Mon Apr 07, 2003 10:56 am    Post subject: Reply with quote

Acolyte

Joined: 27 Mar 2003
Posts: 64
Location: Arlington, Va

How can I check to see if my username has +connect and +inq on the QM, and +get, +put, +browse, +dsp and +inq on the queues (JMS has no concept of open for read, open for write, so opens for both)?
Back to top
View user's profile Send private message AIM Address
vennela
PostPosted: Mon Apr 07, 2003 11:46 am    Post subject: Reply with quote

Jedi Knight

Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India

the command is
dspmqaut

To set the authorities it is
setmqaut

do dspmqaut -? for usage

-------
Venny
Back to top
View user's profile Send private message Send e-mail Visit poster's website
syangloo
PostPosted: Tue Apr 08, 2003 5:06 pm    Post subject: Reply with quote

Centurion

Joined: 01 Oct 2002
Posts: 120
Location: Kuala Lumpur

Other then checking the authority of you user id to the q and qmgr, please check you MCA field at the SYSTEM.DEF.SVRCONN channel.

I getting the same error at NT box with JMS, but it solve by taking out the user id at MCA fields in the SYSTEM.DEF.SVRCONN.

May be you have try it out.

Good Luck.
Back to top
View user's profile Send private message Yahoo Messenger MSN Messenger
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » General IBM MQ Support » 2035 with server bindings
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.