Author |
Message
|
warrenJ |
Posted: Mon Mar 16, 2009 4:19 pm Post subject: MQSAUTHERRORS to display 2035 errors on Unix systems |
|
|
Apprentice
Joined: 11 Jan 2004 Posts: 29 Location: AUSTRALIA
|
|
Back to top |
|
 |
Toronto_MQ |
Posted: Tue Mar 17, 2009 5:34 am Post subject: |
|
|
 Master
Joined: 10 Jul 2002 Posts: 263 Location: read my name
|
Just out of curiosity, how would this differ from turning on authority events at the queue manager level (other than the obvious messages vs FDCs)?
Cheers
Steve |
|
Back to top |
|
 |
bruce2359 |
Posted: Tue Mar 17, 2009 6:00 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
An FDC seems to me like an overkill for a simple 2035 not authorized reason code. _________________ 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 |
|
 |
PeterPotkay |
Posted: Tue Mar 17, 2009 3:37 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
But having the 2035's show up in the error logs is useful as they provide more info than is present in the Event messages. (use MQS_REPORT_NOAUTH )
Windows does this by default. Nice to see I can add it to UNIX. As part of my upgrade to MQ 6.0.2.6 I will set MQS_REPORT_NOAUTH . _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
warrenJ |
Posted: Tue Mar 17, 2009 4:28 pm Post subject: |
|
|
Apprentice
Joined: 11 Jan 2004 Posts: 29 Location: AUSTRALIA
|
The is a difference between MQS_REPORT_NOAUTH and MQSAUTHERRORS.
MQS_REPORT_NOAUTH will only report Not Auth errors in the AMQERR log IF the userid is defined on the server. Note the Exception section that was added to http://www-01.ibm.com/support/docview.wss?rs=171&uid=swg21299319
MQSAUTHERRORS will report Not Auth errors if the UserId is not known to the server. See Scenario B in the TechNote.
Regarding the question from Steve about the QMgr Authority Events - these don't always tell you the real reason for the Not Auth error. This was the original subject of my PMR with IBM. Part of IBM's response was:
Quote: |
It has been the subject of a few PMRs however. The change team explain as follows: "This is the current and historic behaviour of MQ"
|
|
|
Back to top |
|
 |
vol |
Posted: Tue Mar 17, 2009 10:35 pm Post subject: |
|
|
Acolyte
Joined: 01 Feb 2009 Posts: 69
|
setting MQSAUTHERRORS leaves you open to a flood of errors/FDCs if an unknown userID in a client makes repeated connection attempts. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Wed Mar 18, 2009 7:21 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
warrenJ wrote: |
MQS_REPORT_NOAUTH will only report Not Auth errors in the AMQERR log IF the userid is defined on the server. Note the Exception section that was added to http://www-01.ibm.com/support/docview.wss?rs=171&uid=swg21299319
MQSAUTHERRORS will report Not Auth errors if the UserId is not known to the server. See Scenario B in the TechNote.
|
Hmmm, I wonder if a Domain ID qualifies as "When the UserId against which the authorization check is made, is not available on the system". Will have to test that. If true, then MQSAUTHERRORS is a lot less useful.
Love this logic:
Quote: |
Exception:
When the UserId against which the authorization check is made, is not available on the system, then:
MQ V7.0: No messages are written to the error log. That is, AMQ8077 or AMQ9209 are not written in the log.
MQ V5.3, MQ V6.0: No AMQ8077 message is written to the error log. However, the following error message may be recorded:
AMQ9209: Connection to host 'ipAddress' closed.
|
Not only will it record an entry in the log that is completely misleading, but it "may" do it. What else might it do?
warrenJ wrote: |
Part of IBM's response was:
Quote: |
It has been the subject of a few PMRs however. The change team explain as follows: "This is the current and historic behaviour of MQ"
|
|
That is such a lame answer. The Event messages don't tell you what option the ID in question is getting the 2035, just the MQ API call. On Windows I go to the MQ error log and get the exact option that is failing. Either the Event message needs to have this info, ot the MQ error logs on all platforms need to act like they do on Windows. How else do they expect us to work the problem?
I am submitting this enhancement request via
http://www-01.ibm.com/support/docview.wss?uid=swg21266802 _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
warrenJ |
Posted: Fri Mar 20, 2009 4:17 am Post subject: |
|
|
Apprentice
Joined: 11 Jan 2004 Posts: 29 Location: AUSTRALIA
|
Couldn't agree more. You get all the information automatically under Windows but not on "Unix" - crazy.
Also the internal MQ code which is producing the Authority Event messages (to the SYSTEM.ADMIN.QMGR.EVENT queue) can produce a totally different authority error reason than the one generated to the AMQERR001.LOG - great for problem solving.
The issue I was investigating couldn't be solved via the Authority Event messages as they were totally misleading. |
|
Back to top |
|
 |
|