| Author |
Message
|
| mqonnet |
 Posted: Tue Jan 07, 2003 6:36 am Post subject: |
 |
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
What userid you are logged in as after you turn off the authorization.
Whats the error message that you get.
How do you conclude that the authorization has not been turned off.
Cheers.
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
| Back to top |
|
 |
| mqonnet |
| Posted: Tue Jan 07, 2003 7:38 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Works fine for me.
Create a qm with defaults. OAM set. using logon MQM.FRED. Then logged on as TEST.MANAGER which is not in the MQM group. Ran amqsput, it failed with 2035 on mqconn. Added a principal to this userid and it worked fine.
Removed the principal.
Ended the qm.
Changed the qmini settings MQAUTH to "Off".
restarted the qm.
Ran amqsput and it put the message just fine. Note, i have already removed the principal.
So, i would go back and check whats wrong in your version. Whats different than what i posted above.
Hope this helps.
Cheers.
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
| Back to top |
|
|
| mqonnet |
| Posted: Wed Jan 08, 2003 6:54 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Ok.
Let me clarify all your doubts as well resolve your issue.
1) You need to have a principal defined for argos.manager for the QM in question. Without that you can do nothing. Be it with or without OAM.
2) If you have OAM enabled, then this user is checked for authorities on the objects, which include the Qmgr and the queue you are trying to put messages to, in your case remote queue. And this could be achieved using SETMQAUT.
3) If you have OAM disabled, then this user is NOT checked for any authorities on any object and you can access any object.
But underlying theme for all of the above points is, that you OUGHT to have a principal defined. Otherwise you are not recognized as a user to allow connection to any object.
So to summarise, in step 6, you MUST see argos.manager added to this QM for your scenario to work. There is no other alternative, unfortunately.
Hope this helps.
Cheers.
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
| Back to top |
|
|
| mqonnet |
| Posted: Thu Jan 09, 2003 6:02 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Please post the output of DSPMQUSR.
In my environment though it worked.
As for PTF level, i am on CSD01. But i dont think the code level has anything to do with your problem. Because it is all OAM thing.
Cheers.
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
| Back to top |
|
|
| LuisFer |
| Posted: Thu Jan 09, 2003 9:06 am Post subject: |
|
|
Partisan
Joined: 17 Aug 2002
Posts: 302
|
In my installation we have deleted all lines references OAM stanzas in the QMINI file & protected by SAFEGUARD following:
Add the OTHER.USER to GROUP MQM (departm. SECURITY five Days!!!)
Using ALTMQUSR add the OTHER.USER to QMGR:..
ALTMQUSR -m QCMT01 -p OTHER -u OTHER.USER
\AP1.$SPOOL1.PROJCL 2> dspmqusr -m QCMT01
\AP1.$SPOOL1.PROJCL 2..
:Principal Userid Username Alias GroupName GroupType :
: 0.1 :
:NOBODY 0.0 :
:SUPER 255.1 SUPER.EXPLOT n SUPER a :
: MQM s :
:mqm 241.255 MQM.MANAGER n MQM a :
In this sample is a SUPER user but equal to other user.
We protected the QFiles by SAFEGUARD too, by $VOL.SUBVOL restricted to this users. |
|
| Back to top |
|
|
| LuisFer |
| Posted: Thu Jan 09, 2003 9:39 am Post subject: |
|
|
Partisan
Joined: 17 Aug 2002
Posts: 302
|
For the QMINIMEM problem in the last Efix C1EFIX2 resolved this problem.
We rename the $vol.subvol.QMINIMEM always after endmqm & before strmqm (and the CCSIDMEM if necesary).
Sorry, but:
Do you feel the amount of TMF tx is incremented over SDR CHL with NpmSpeed(FAST) ???
Thanks |
|
| Back to top |
|
|
| LuisFer |
| Posted: Thu Jan 09, 2003 10:01 am Post subject: |
|
|
Partisan
Joined: 17 Aug 2002
Posts: 302
|
We have received it by CDROM from IBM.
I Know that there is a C1EFIX3. |
|
| Back to top |
|
|
| LuisFer |
| Posted: Thu Jan 09, 2003 8:53 pm Post subject: |
|
|
Partisan
Joined: 17 Aug 2002
Posts: 302
|
 With the apply of C1EFIX2 or C1EFIX3 the MQSYNC CALL not exist and the applications must remove this one |
|
| Back to top |
|
|
|
|
