| Author |
Message
|
| zen |
 Posted: Tue May 17, 2005 11:52 pm Post subject: Where and How do I view MQ logs? |
 |
|
Apprentice
Joined: 11 May 2005
Posts: 32
Location: Singapore
|
Hi,
This is my first time to use MQ. Can you please guide me on how can I view the logs of MQ? Specifically I wanted to view the userid that is being submitted by a client connection to the MQ. I found some logs and I wanted to view them but they seem to be not in plain text format. Is there a tool that I need to run to view these files?
Your help will be greatly appreciated.
Thanks a lot.
zen |
|
| Back to top |
|
 |
| Michael Dag |
| Posted: Wed May 18, 2005 12:29 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
The MQ Log format is an IBM internal only format.
AFAIK there are no tools to view the MQ Logs
There is one tool that can read the MQ Log files for playback, it's called ReQuest from Cressida
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| sebastianhirt |
| Posted: Wed May 18, 2005 12:57 am Post subject: |
|
|
Yatiri
Joined: 07 Jun 2004
Posts: 620
Location: Germany
|
Hi,
| Quote: |
| I found some logs and I wanted to view them but they seem to be not in plain text format. Is there a tool that I need to run to view these files? |
You can try the dmpmqlog command. This is showing you the active log in a more readable format.
But I am not sure whether or not this helps you any, because I never used it personally.
| Quote: |
| Specifically I wanted to view the userid that is being submitted by a client connection to the MQ |
Well I am only assuming on this one, but shouldn't the messages 'Put User ID' be the same as the userid that is used to do the Client connection?
EDIT: If there is a message put trough this client connection, of course.
cheers
Sebastian |
|
| Back to top |
|
|
| zen |
| Posted: Wed May 18, 2005 12:59 am Post subject: |
|
|
Apprentice
Joined: 11 May 2005
Posts: 32
Location: Singapore
|
Ok, i'll try to look at this ReQuest from Cressida. However, I am really not sure where is the correct log/error files that I have to check to view the userid that's being passed by the client connection application. Any idea where it is located?
Thanks. |
|
| Back to top |
|
|
| zen |
| Posted: Wed May 18, 2005 1:09 am Post subject: |
|
|
Apprentice
Joined: 11 May 2005
Posts: 32
Location: Singapore
|
Thanks for the reply sebastian. I tried dmqpmlog and it doesn't say much and it isn't the data that I needed.
On your second comment, my problem is the client program already encountered a "connection refused" error during the connection establishment phase. So there were no messages sent first. In my client program, I set the MQEnvironment variables including the userid variable. I just wanted to check if the correct userid is being passed to the QM during the connection establishment.
Any ideas?
Thanks a lot. |
|
| Back to top |
|
|
| sebastianhirt |
| Posted: Wed May 18, 2005 1:15 am Post subject: |
|
|
Yatiri
Joined: 07 Jun 2004
Posts: 620
Location: Germany
|
What operating system are you running?
On AIX (I would guess that is the same for most of the other Unix systems as well!?) the error logs are under
/<mqm install dir>/errors
/<mqm install dir>/qmgrs/<qmgrname>/errors
/<mqm install dir>/qmgrs/@system/errors
where <mqm install dir> is per default /var/mqm
on Windows
<mqm install dir>\errors
<mqm install dir>\qmgrs\<qmgrname>\errors
<mqm install dir>\qmgrs\@sustem\errors
where <mqm install dir> is per default c:\Program Files\IBM\WebSpehere MQ\
The logs that are located under <mqm install dir>\logs (or <mqm install dir>/logs) are the so called Active logs.
But I doubt that you would see the UserID in the error logs.
Have you checked whether you can connect from Server A to Server B is possible at all? (Firewalls in between?)
Have you setup SSL or a security exit that might refuse you to connect?
Have you set up OAM Security that would refuse the user you are using to connect to the Queue Manager?
Are you sure your MQ Server Variable is setup correct? |
|
| Back to top |
|
|
| zen |
| Posted: Wed May 18, 2005 1:25 am Post subject: |
|
|
Apprentice
Joined: 11 May 2005
Posts: 32
Location: Singapore
|
Hi, thank you very much for your reply. The server OS is Linux while the client machine is win2k. We first tried the client connection without setting a value for MCAUSER and w/o setting the value of MQEnvironment.userID and the program worked fine. Only when we set the the MCAUSER value to a userid and set the MQEnvironment.userID and other MQEnvironment variables then we encountered the "2035: Connection Refused Exception".
I looked at the display channel(channel name) and i noticed that there's a variable SSLCAUTH(REQUIRED). Does that affect client connection in my case? I just wanted to know before I asked our admin to maybe change the value of that variable.
Wholatta thanks. |
|
| Back to top |
|
|
| sebastianhirt |
| Posted: Wed May 18, 2005 1:35 am Post subject: |
|
|
Yatiri
Joined: 07 Jun 2004
Posts: 620
Location: Germany
|
| Quote: |
| I looked at the display channel(channel name) and i noticed that there's a variable SSLCAUTH(REQUIRED). Does that affect client connection in my case? I just wanted to know before I asked our admin to maybe change the value of that variable. |
That's default. Don't worry about this for now.
| Quote: |
"2035: Connection Refused Exception".
|
That means that the user you are trying has no permission to connect to the queue manager
Try:
dmpmqaut -m <qmgr name> -t qmgr
The output will look like this
| Code: |
H:\>dmpmqaut -m myqm -t qmgr
profile: SELF
object type: qmgr
entity: Username
entity type: principal
authority: allmqi crt dlt chg dsp
- - - - - - - -
profile: @CLASS
object type: qmgr
entity: Username
entity type: principal
authority: crt |
Carefully check what permissions your mcauser is having on that qm.
You can change the permissions of your queue manager with the setmqaut comand. |
|
| Back to top |
|
|
| zen |
| Posted: Wed May 18, 2005 2:03 am Post subject: |
|
|
Apprentice
Joined: 11 May 2005
Posts: 32
Location: Singapore
|
Hi, below is the result of dmpmqaut:
profile: self
object type: qmgr
entity: mqm
entity type: principal
authority: allmqi crt dlt chg dsp
- - - - - - - -
profile: self
object type: qmgr
entity: users
entity type: group
authority: inq set connect altusr dlt chg dsp setid setall
- - - - - - - -
profile: @class
object type: qmgr
entity: mqm
entity type: principal
authority: crt
- - - - - - - -
profile: @class
object type: qmgr
entity: users
entity type: group
authority: crt
Any mistake? |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Wed May 18, 2005 2:25 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| zen wrote: |
We first tried the client connection without setting a value for MCAUSER and w/o setting the value of MQEnvironment.userID and the program worked fine. Only when we set the the MCAUSER value to a userid and set the MQEnvironment.userID and other MQEnvironment variables then we encountered the "2035: Connection Refused Exception".
|
What did you put in the MCAUSER?
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| sebastianhirt |
| Posted: Wed May 18, 2005 4:03 am Post subject: |
|
|
Yatiri
Joined: 07 Jun 2004
Posts: 620
Location: Germany
|
| Code: |
profile: self
object type: qmgr
entity: users
entity type: group
authority: inq set connect altusr dlt chg dsp setid setall
|
I am not that much into Linux. But isn't 'users' on Linux the same as 'staff' on AIX? Or in other words the group where everybody is in?
Your output has in it:
- Permissions for the mqm user
- permission for the groups users
The group 'users' can do as good as everything. But it cannot do mqi calls, which you need to be able to do, in order to connect to the queue manager, put to queues, get from queues etc. from a client connection.
That means:
If you have for example your MCAUSER set to let me say GEORGE who is a member if the group 'users', you are allowed to do a lot of things, but not to do MQI calls to the queue manager.
If you don't have an MCAUSER ID set, you will have in most of the scenarios I can think off 'mqm' rights, which is granting you "root" rights to MQ.
What you could try (and what should work) is assign the entity users for the queue manager and all queue objects you need to access the right "allmqi".
If my assumption is right (the one that users equals to staff in AIX):
I wouldn't advice to do so, because then everybody with this group would have the same rights (in your case plenty of them). I would like to recommend you then, to create another group, and assign to this group the necessary rights. |
|
| Back to top |
|
|
| sebastianhirt |
| Posted: Wed May 18, 2005 4:26 am Post subject: |
|
|
Yatiri
Joined: 07 Jun 2004
Posts: 620
Location: Germany
|
OK OK... Now that I read the manual, I have to admit, that I should have been doing it before replying...
| Quote: |
Authorizations for MQI calls
altusr Use another user's authority for MQOPEN and MQPUT1 calls.
browse Retrieve a message from a queue using an MQGET call with the BROWSE option.
connect Connect the application to the specified queue manager using an MQCONN call.
get Retrieve a message from a queue using an MQGET call.
inq Make an inquiry on a specific queue using an MQINQ call.
put Put a message on a specific queue using an MQPUT call.
set Set attributes on a queue from the MQI using an MQSET call. |
Your 'users' group has all single permissions that are in allmqi.
So the most interesting question stays the one that Michael asks...
What is the user you have configured as your MCAUSER.
Is that user member of the group 'users'?
If you changed security related things in the past, did you refresh security?
| Quote: |
A principal can belong to more than one group (its group set) and has the aggregate of all the authorities granted to each group in its group set. These authorities are cached, so any changes you make to the principal's group membership are not recognized until the queue manager is restarted, unless you issue the MQSC command REFRESH SECURITY (or the PCF equivalent).
|
|
|
| Back to top |
|
|
| zen |
| Posted: Wed May 18, 2005 5:19 pm Post subject: |
|
|
Apprentice
Joined: 11 May 2005
Posts: 32
Location: Singapore
|
Hi,
Thanks for your replies. The MCAUSER is set to userid user001 which belonged to the mqm group. In the client program, we set the variables of MQEnvironment including the userid which is "MQEnvironment.userID = user001". Also, we already issued a REFRESH SECURITY and we even restarted the QM, still the same 2035 error came out.
Thanks a lot. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed May 18, 2005 6:38 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Yes but is usr001 the user running the client program ??  |
|
| Back to top |
|
|
| zen |
| Posted: Wed May 18, 2005 7:47 pm Post subject: |
|
|
Apprentice
Joined: 11 May 2005
Posts: 32
Location: Singapore
|
Hi,
What do you mean by the user running the program? Are you referring to the user that is currently logged in on the client machine? Currently my userid logged in to the client machine is "workstation006". But in my client program, I specified the MQEnvironment to use my server id "user001" (MQEnvironment.userID = user001). Do I have to use the same server login userid with the client login userid? Doesn' that defeat the purpose of being able to set the MQEnvironment.userID?
Thanks a lot. |
|
| Back to top |
|
|
|
|
