Well, I donât think I agree with your suggestion of MQRC_ENVIRONMNENT_ERROR. Personally I think that is just as misleading as MQRC_Q_MGR_NAME_ERROR. It implies that had you issued the same command in a different environment (like CICS, or a threaded program) it would have worked, whereas clearly it wouldnât. However, you could have a strong argument here for a different reason code in this situation. I think Iâd be leaning towards something like MQRC_CHANNEL_CONFIG_ERROR and expanding itâs definition a bit. Or indeed expanding the definition of MQRC_Q_MGR_NAME in the manuals.
I suspect the main problem here is that this situation does not seem to write an error message to the client log which surprises me. I had thought that all failing MQCONN( X ) calls would have resulted in an error message to the log. I agree entirely that for this situation one should not have to resort to looking at traces,
Cheers,
Paul.
Paul Clarke
www.mqgem.com
From: T.Rob
Sent: Saturday, December 21, 2013 3:41 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Mystery 2058
Hi Paul,
My colleague is attempting to debug an SSL session and was getting 2393 MQRC_SSL_INITIALIZATION_ERROR. When he began to see 2058 MQRC_Q_MGR_NAME_ERROR we assumed he had gotten past the SSL problems and was now connecting to *something* and that whatever it was it was a QMgr, just not the one we expected. We assumed that because 2058 is exactly what you get when a client succeeds in connecting to a QMgr but it is the wrong one.
So, we looked in the Infocenter and it says "the value specified for the QMgrName parameter is not valid or not known." But the value *is* known and valid, we just tried it with amqssslc and it worked. Literally copy and paste the values from the previous command line.
So a 2058 can meanâŠ
· User botched the value with invalid characters so the MQCONN(X) itself is bad..
· The user input and MQCONN(X) are great but the value presented can't be found in the CCDT.
· The user input, MQCONN(X) and the CCDT are great but the QMgr it reached wasn't the one expected.
In other words, the same error code can represent problems at the command line, in the configuration or in negotiation with the QMgr after an otherwise successful connection. Yeah, I'd say there's real value in making the diagnostic smart enough to distinguish between problems across these three different areas.
What I did not realize before tonight was that it is possible to pass a known good value to the client and get a 2058. The description MQRC_Q_MGR_NAME_ERROR suggests that in some way or another the QMgr name has been evaluated. In this case it can't find a CCDT and there's nothing in the environment to tell it the CONNAME and channel name, the QMgr name is the *only* valid thing it has and yet we get back MQRC_Q_MGR_NAME_ERROR. If there's no environment variables and no mqclient.ini file to evaluate against, 2012 MQRC_ENVIRONMENT_ERROR would at least point the user in the right direction.
I used to get on L2 and L3 Support's case for jumping the customer straight to traces for 2035 errors when it's so much easier to enable auth events. Now I know why they do this. Because certain problems are simply intractable without a trace, and tracing everything means you don't have to remember which problems have diagnostics and which do not.
Now I have an idea this is "working as designed" I won't advise my colleague to open a PMR but rather to brush up on their client tracing skills.
Thanks â T.Rob
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Paul Clarke
Sent: Friday, December 20, 2013 19:19 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Mystery 2058
T.Rob,
When the client was first written the brief was to not introduce any new reason codes. This was so that existing applications would get the same reason codes back as they got in the local case. The client therefore had essentially 2058 and 2059 to play with when the connect failed. I can well believe that 2058 means âI can not find a resolution to the queue manager you specified on the MQCONN verbâ.
As Iâm sure you know MQ V7 relaxed the client rules and a number of new reason codes were added to make the client error cases more specific. Reason codes like MQRC_HOST_NOT_AVAILABLE. Needless to say some customers were not happy about the introduction of new reason codes so we needed to be conscious of that fact and only introduce new reason codes where we felt it gave real value. As you may imagine there are literally hundreds of reasons why an MQCONN over a client may fail, it is just not feasible to give them all a new reason code.
In the case you mention what reason code would you have expected ? Or are you saying there should be a new one ?
Cheers,
Paul.
Paul Clarke
www.mqgem.com
From: T.Rob
Sent: Friday, December 20, 2013 11:35 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Mystery 2058
Got a standard WMQ 7.5 Server install with no default QMgr defined.
Default mqclient.ini
No MQSERVER, MQCHLLIB or MQCHLTAB variables.
Execute amqsputc returns 2058 MQRC_Q_MGR_NAME_ERROR.
I don't see how this is the right error. The client cannot have connected to anything, right? Shouldn't it return an error indicating that no connection info was provided? The error suggests that it connected to *something* and what it found was not the QMgr it expected. But it could not have connected to anything.
-- T.Rob
--------------------------------------------------------------------------------
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
--------------------------------------------------------------------------------
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
--------------------------------------------------------------------------------
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html