| Author |
Message
|
| dude1 |
 Posted: Tue Feb 20, 2007 11:57 am Post subject: Username Pwd authentication |
 |
|
Novice
Joined: 20 Feb 2007
Posts: 10
|
m_QManager.setName("DummyQM");
m_Channel.setChannelName("DUMMYCH");
m_Channel.setTransportType(MQXPT_TCP);
CString ConnectionString;
ConnectionString.Format("%s(%d)",m_IPAddress,m_TCPPort);
m_Channel.setConnectionName(ConnectionString);
//Associate this channel with the queue manager
m_QManager.setChannelReference(m_Channel);
//Connect to the queue manager
!m_QManager.connect()
This always throws me an error with reason Code 2063...
I understand its some authentication issue... but the problem is
i dont how to specify the username and password...
i tried
m_QManager.setUserId("Username");
m_QManager.setPassword("pwd1234");
before connecting... but no change...
i tried similar things with the channel object too...
I am new to MQ... Please bare with these basic questions...n help me out of this issue...
vbn |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Feb 21, 2007 12:38 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
What version of MQ? On what platform? Do the samples work?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| dude1 |
| Posted: Wed Feb 21, 2007 6:31 am Post subject: |
|
|
Novice
Joined: 20 Feb 2007
Posts: 10
|
its mq 6.0 on windos environment ...
Rt now its trying to authenticate with the user who is currently looged in...
but i want to authenticate with a seperate the user name and password...
The documenation is not that informative... how and where should I specify the user name and password?? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Feb 21, 2007 6:32 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You don't.
Not unless there's a security exit involved.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Feb 21, 2007 6:36 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Verifying against the logged on user is the default behaviour. Is the queue manager local to the machine you're running the code on; a 2063 can sometimes be caused by a Windows "mqm" user being passed to a Unix queue manager. Security violations are usually 2035.
Not that code should be run under such a user anyway of course....
If you want to provide a different user id to MQ, consider setting the MCAUser attribute of the connection channel. AFAIK you can't supply it directly via connection code, and I'm not convinced of the wisdom of coding passwords into applications at the best of times. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| ydsk |
| Posted: Fri Mar 30, 2007 6:24 am Post subject: |
|
|
Chevalier
Joined: 23 May 2005
Posts: 410
|
Hi,
I am facing a slightly similar problem.
My scenario looks like:
C++ module on my Windows PC--->MQ on Aix---->MQ/IMS bridge/IMS on zOS.
I am logging in to the Windows box with my windows id 'ydsk', and my C++ module is able to successfully connect to the qmgr on AIX b'cos ydsk has access to connect to the qmgr. The MCAUSER on the svrconn on AIX is blank.
And with each message I am sending another id 'abc' in the MQMD. That id abc is actually coming in from a different C++ module on my machine that calls my C++ module shown above.
To my surprise the id that is going in with each message is becoming ydsk when the msg reaches mainframe. But I need the id to be abc.
Is there any setting I need to do on the mainframe RCVR channel or elsewhere to preserve the id abc all the way upto mainframe ?
Pls suggest.
thnx.
ydsk. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Mar 30, 2007 7:05 am Post subject: |
|
|
Guest
|
Same answer for z/OS; namely: alter the receiver channel MCAUSER. By default, the qmgr inserts the logged on userid into the MQMDs username field (along with the application program name and other Context fields).
If your application has authority to set context fields (not the default), it can change the context fields. If it doesn't have authority, the qmgr ignores what you may have moved to the context fields - as you have discovered. Refer to the Application Programmers Reference. |
|
| Back to top |
|
|
| ydsk |
| Posted: Fri Mar 30, 2007 8:04 am Post subject: |
|
|
Chevalier
Joined: 23 May 2005
Posts: 410
|
My appl has authority to set context fields. And changing MCAUSER isn't allowed in our environment.
Any other solutions please ?
thnx.
ydsk. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Mar 30, 2007 8:21 am Post subject: |
|
|
Guest
|
| If your application already has authority to use set the context fields, but the context fields are not being set, make sure the MQPMO options include MQPMO_SET_IDENTITY_CONTEXT or MQPMO_SET_ALL_CONTEXT before the MQPUT. |
|
| Back to top |
|
|
| ydsk |
| Posted: Fri Mar 30, 2007 8:41 am Post subject: |
|
|
Chevalier
Joined: 23 May 2005
Posts: 410
|
Great Bruce, that worked.
I also had to use MQOO_SET_IDENTITY_CONTEXT when I opened the queue.
Now I am seeing the correct user-id in MQMD when I stopped the message on the AIX xmit queue while going to mainframe.
thanks.
ydsk. |
|
| Back to top |
|
|
|
|
