| Author |
Message
|
| Sam Uppu |
 Posted: Tue Aug 02, 2011 1:14 pm Post subject: MQ OAM permissions issue |
 |
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
Hi Guys,
We have a cluster queue called CLUSTERQ defined on mainframe QMgr. The application trying to access that queue for putting msgs from a Qmgr on unix which is part of the same MQ cluster.
This setup is done by someone prior to me.
The application is able to put msgs onto cluster queue by connecting MQclient via SVRCONN channel in PROD where as the application is getting 2035 in Test environment.
I was under the impression that we need to have a locally defined Alias queue for every cluster queue(which is defined remotely). In our prod environment, the app is able to put msgs onto cluster queue(defined on mainframe) by connecting thru Qmgr on unix side.
I dont see any Alias queue in PROD which points to actual cluster queue on mainframe.
| Code: |
mqm@server1# ./dspmqaut -m QM1 -t qmgr -g group1
Entity group1 has the following authorizations for object QM1:
inq
set
connect
altusr
dlt
chg
dsp
setid
setall |
| Code: |
# ./dspmqaut -m QM1 -t q -n CLUSTERQ -g group1
AMQ7085: Object CLUSTERQ, type q not found. |
Here are the client channel definitions:
| Code: |
dis chl(CLIENT.SVRCONN)
2 : dis chl(CLIENT.SVRCONN)
AMQ8414: Display Channel details.
CHANNEL(CLIENT.SVRCONN) CHLTYPE(SVRCONN)
ALTDATE(2009-12-09) ALTTIME(10.57.00)
COMPHDR(NONE) COMPMSG(NONE)
DESCR( ) HBINT(300)
KAINT(AUTO) MAXMSGL(4194304)
MCAUSER(app1) MONCHL(QMGR)
RCVDATA( ) RCVEXIT( )
SCYDATA( ) SCYEXIT( )
SENDDATA( ) SENDEXIT( )
SSLCAUTH(REQUIRED) SSLCIPH( )
SSLPEER( ) TRPTYPE(TCP)
AMQ8414: Display Channel details.
CHANNEL(CLIENT.SVRCONN) CHLTYPE(CLNTCONN)
ALTDATE(2009-12-09) ALTTIME(11.03.48)
COMPHDR(NONE) COMPMSG(NONE)
CONNAME(server1.com(1423)) DESCR( )
HBINT(300) KAINT(AUTO)
LOCLADDR( ) MAXMSGL(4194304)
MODENAME( ) PASSWORD( )
QMNAME(QM1) RCVDATA( )
RCVEXIT( ) SCYDATA( )
SCYEXIT( ) SENDDATA( )
SENDEXIT( ) SSLCIPH( )
SSLPEER( ) TPNAME( )
TRPTYPE(TCP) USERID( ) |
The id used in MCAUSER, app1 is part of group 'group1' and the group, group1 is provided with the permissions as shown above.
Can you please let me know if I am missing anything here?.
Thanks. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Tue Aug 02, 2011 1:59 pm Post subject: Re: MQ OAM permissions issue |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| Sam Uppu wrote: |
The application is able to put msgs onto cluster queue by connecting MQclient via SVRCONN channel in PROD where as the application is getting 2035 in Test environment.
|
What MQ call resulted in the 2035 in test? What userid?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Aug 02, 2011 2:03 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Let me get this straight: you have an application connecting via client to a UNIX-based queue manager, which then routes messages to a z/OS-based queue manager via cluster channels?
As you stated "...The application is able to put msgs onto cluster queue..." in the Production environment I suggest you check the Production-environment UNIX queue manager authorities, specifically what authorities that group1 has for the SYSTEM.CLUSTER.TRANSMIT.QUEUE.
_________________
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 |
|
|
| bruce2359 |
| Posted: Tue Aug 02, 2011 2:24 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
I read this as the client app is connecting to the z/OS qmgr, and getting the 2035 on z/OS.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Aug 02, 2011 2:38 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| bruce2359 wrote: |
| I read this as the client app is connecting to the z/OS qmgr, and getting the 2035 on z/OS. |
The poster stated "...In our prod environment, the app is able to put msgs onto cluster queue(defined on mainframe) by connecting thru Qmgr on unix side...".
_________________
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 |
|
|
| Sam Uppu |
| Posted: Tue Aug 02, 2011 3:13 pm Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| exerk wrote: |
Let me get this straight: you have an application connecting via client to a UNIX-based queue manager, which then routes messages to a z/OS-based queue manager via cluster channels?
As you stated "...The application is able to put msgs onto cluster queue..." in the Production environment I suggest you check the Production-environment UNIX queue manager authorities, specifically what authorities that group1 has for the SYSTEM.CLUSTER.TRANSMIT.QUEUE. |
Yes. You are right. The user group, group1 got below permissions on SCTQ in PROD where as not in QA. Thatswhy the app dont see any issue in PROD whereas issues in QA.
# ./dspmqaut -m QM1 -t q -n SYSTEM.CLUSTER.TRANSMIT.QUEUE -g group1
Entity group1 has the following authorizations for object SYSTEM.CLUSTER.TRANSMIT.QUEUE:
get
browse
put
inq
set
passid
passall
setid
setall
Question:
Do you think of any case where we need more than connect & inq permissions at the QMgr level(on unix)?.
Thanks. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Aug 02, 2011 3:22 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Sam Uppu wrote: |
Question:Do you think of any case where we need more than connect & inq permissions at the QMgr level(on unix)? |
Yes. The case where an application requires more than just connect and inquire, and that depends on the application requirements.
I suggest you sort out your Production environment because at the moment it's very much a case of "where do you want to go in the cluster today?" for that application, including system queues on other queue managers.
_________________
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 |
|
|
|
|
