Connection to zOS MQ Manager

Got the same error with 1.7.2. Any ideas?

Good morning Sebastian,

In which stage you got this error - during initial connect to MQM or while browsing queues?

Did you update or use the fresh install?

I am connected to my zOS MQM right now and everithing is working fine.

fresh install - during initial connect to MQM. ("Connection failed (2035-2035)"). With IBM WebSphere MQ Explorer everything is fine.

Are you using same logon credentials as on zOS?

same credentials. in this case no password is needed. only user.

True. I assume IP address, port and channel are correct too.

yes

works with IBM WebSphere MQ Explorer 7.5

Can you, please, post a log file? It is in C:\ProgramData\Dot Consulting\MQ Explorer Plus For Websphere.

there is no log file. only licence.

i found the log in appdata\local. i see there is a proxy auth problem (407). how can i fix it?

Check then in user's Local profile in Dot Consulting\MQ Explorer Plus For Websphere\Logs

is it possible to configure the proxy settings for your application?

To solve the proxy issue, you can add the following to the application configuration file (Dotc.MQExplorerPlus.Websphere.exe.config located in the installation folder you choose) just before the closing tag "</configuration>"

  <system.net>
    <defaultProxy useDefaultCredentials="true" />
  </system.net>

I am not a developer of MQ Explorer Plus, Bertrand Giot is. I am only helping him test it, especially on zOS.

This proxy question should wait for Bertrand to answer, sorry.

Anyway, post your log so we can analyze it.

Hi Sebastian,

Can you post the log file or send it to support_mqexplorerplus@dotconsulting.be ?

The proxy issue is probably linked to the startup of the application checking if a new version is there...so not linked to your zOS connectivity issue.

Also, you should find useful information on zOS logs. Are we sure the user id is properly passed ? which one ? the correct one ? the zOS logs should help us a lot.

Thank you,

Bertrand Giot.

application.log:

2017-09-07 09:18:44.6348::DOMAIN\USER::ERROR::System.Net.Http.HttpRequestException: Fehler beim Senden der Anforderung.
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei Dotc.MQExplorerPlus.Application.WebAPIClient.Rest.<PostAsJsonAsync>d__7`1.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei Dotc.MQExplorerPlus.Application.WebAPIClient.Rest.<LogStartupAsync>d__10.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei Dotc.MQExplorerPlus.Application.Controllers.ApplicationController.<LogStartupAsync>d__30.MoveNext()
--- INNER EXCEPTION ---
|||System.Net.WebException: Der Remoteserver hat einen Fehler zurückgegeben: (407) Proxyauthentifizierung erforderlich.
|||   bei System.Net.HttpWebRequest.EndGetRequestStream(IAsyncResult asyncResult, TransportContext& context)
   bei System.Net.Http.HttpClientHandler.GetRequestStreamCallback(IAsyncResult ar)

2017-09-07 09:18:44.8588::DOMAIN\USER::ERROR::System.Net.Http.HttpRequestException: Fehler beim Senden der Anforderung.
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei Dotc.MQExplorerPlus.Application.WebAPIClient.Rest.<GetAsync>d__6`1.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei Dotc.MQExplorerPlus.Application.WebAPIClient.Rest.<GetLatestVersionInfoAsync>d__9.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei Dotc.MQExplorerPlus.Application.Models.VersionChecker.<CheckLatestVersionAsync>d__4.MoveNext()
--- INNER EXCEPTION ---
|||System.Net.WebException: Der Remoteserver hat einen Fehler zurückgegeben: (407) Proxyauthentifizierung erforderlich.
|||   bei System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
   bei System.Net.Http.HttpClientHandler.GetResponseCallback(IAsyncResult ar)

2017-09-07 09:54:05.9804::DOMAIN\USER::ERROR::System.Net.Http.HttpRequestException: Fehler beim Senden der Anforderung.
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei Dotc.MQExplorerPlus.Application.WebAPIClient.Rest.<PostAsJsonAsync>d__7`1.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei Dotc.MQExplorerPlus.Application.WebAPIClient.Rest.<LogStartupAsync>d__10.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei Dotc.MQExplorerPlus.Application.Controllers.ApplicationController.<LogStartupAsync>d__30.MoveNext()
--- INNER EXCEPTION ---
|||System.Net.WebException: Der Remoteserver hat einen Fehler zurückgegeben: (407) Proxyauthentifizierung erforderlich.
|||   bei System.Net.HttpWebRequest.EndGetRequestStream(IAsyncResult asyncResult, TransportContext& context)
   bei System.Net.Http.HttpClientHandler.GetRequestStreamCallback(IAsyncResult ar)

2017-09-07 09:54:06.2014::DOMAIN\USER::ERROR::System.Net.Http.HttpRequestException: Fehler beim Senden der Anforderung.
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei Dotc.MQExplorerPlus.Application.WebAPIClient.Rest.<GetAsync>d__6`1.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei Dotc.MQExplorerPlus.Application.WebAPIClient.Rest.<GetLatestVersionInfoAsync>d__9.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei Dotc.MQExplorerPlus.Application.Models.VersionChecker.<CheckLatestVersionAsync>d__4.MoveNext()
--- INNER EXCEPTION ---
|||System.Net.WebException: Der Remoteserver hat einen Fehler zurückgegeben: (407) Proxyauthentifizierung erforderlich.
|||   bei System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
   bei System.Net.Http.HttpClientHandler.GetResponseCallback(IAsyncResult ar)

Thanks! I confirm the proxy issue is only linked to the fact that the application is trying to contact our version server to see if a new version is available.  So, regarding your zOS connection issue, we can ignore the proxy issue. not related.

Do you have other things in the log file more around the time you try to connect to zOS ?

Can you post complete log to see all problematic steps reported? It would be nice if you can attach/send complete log file.

this is the complete log in the given directory (2017-09-07.log). are there any other local log files located? unfortunately, i have no access to the zOS logs.

Without detail information reported by the queue manager on zOS, it will be difficult to find out why you have an "access denied" error. Can you contact someone who can have a look at the logs on the mainframe ?

I think copy-pasting the log file content to this thread has truncated it.  Can you send the file by e-mail to support_mqexplorerplus@dotconsulting.be ?

Thank you.

the user is correct. the proxy seems not to be the problem. connection fails anyway (2035-2035).

That is strange. Log should show us MQ connect error.

Lets go try different approach.

Please remove user credentials from connect connection definition and see what will happend. I just did it and it generates 2035-MQRC_NOT_AUTHORIZED error dispalyed and written in log.

Then post log again.

i asked the support. they said, there is no client user given.

but i filled in the correct "User Id" in the dialouge "Select Queue Manager...".

Is it a standard RACF system for authentication ?

yes

Please try without specifying user name as I suggested and post/email created log. We need generated error info to pinpoint this issue.

i tried. it comes 2035-2035 again and no log entry on client side. server side same. the mq support gave me the server specs: platform Unix, Control level: 710, Version: 07010006. does it help somehow?

Can we have a extract of the zOS log ? sometimes Websphere MQ provides some clues for helping us... sorry but I'm a bit "blind" without the zOS logs...  The error is returned by the queue manager, so we need to see the queue manager logs to find out why he refused the access.  Is your queue manager configured to simply use the MCAUser on the channel ? can you try by using/creating another channel ?

So MQM is not on zOS but on UNIX. It doesn't solve enything but is good to know.

hooo! I missed that one. I was going in the wrong direction. Thank you Zoran to point this out!

Are you able to work on that UNIX server? to log on using SSH and to browse MQM settings? If not, can you ask MQM support to do it?

i can browse the ws-manager settings with my ibm websphere mq explorer.

BTW, can you get more info on MQM UNIX server - UNIX brand, version, ...?

no direct access to the server via ssh

Please ask for UNIX OS specs. I can maybe reproduce it in my environment.

Thank you Zoran!

MQ 7.1

Sebastian, I ment the UNIX server data on which MQ is running, not the MQ server data.

Linux vvm267 2.6.18-238.5.1.el5 #1 SMP Mon Feb 21 05:52:39 EST 2011 x86_64 x86_64 x86_64 GNU/Linux

As we now understand it's a Unix machine having the queue manager running on it, from the basic tests I did regarding connectivity, I had to always provide a password with the user id... can you explain how we can set up an environment with this kind of security configuration, so MQ doesn't require a password for user authentication ?

True. no password is passed. only user. the support said, the is always a "." (dot) as password. the message is:

09/07/2017 11:32:03 AM - Process(3173.22172) User(mqm) Program(amqrmppa)

                    Host(vvm267) Installation(Installation1)

                    VRMF(7.1.0.6) QMgr(QMMANAGER)

AMQ9777: Channel was blocked

EXPLANATION:

The inbound channel 'CHANNEL.SVRCONN' was blocked from address '10.xxx.xxx.xxx'

because the active values of the channel matched a record configured with

USERSRC(NOACCESS). The active values of the channel were 'CLNTUSER('.

ACTION:

Contact the systems administrator, who should examine the channel

authentication records to ensure that the correct settings have been

configured. The ALTER QMGR CHLAUTH switch is used to control whether channel

authentication records are used. The command DISPLAY CHLAUTH can be used to

query the channel authentication records.

what mq client version do you use?

The mq client version depends.  If you run the tool on a machine with MQ installed locally, it will use that version. Otherwise, it will use the version provided with the tool that is version 9.0.0.0.

Did you try to put the <dot> password along with the user id, instead of no password ?

OK, it is Linux, not UNIX, similar but not the same.

Can you ask for output of command lsb_release -a ?

"-a" option is unknown. output of lsb_release is 

LSB Version:    :core-4.0-amd64:core-4.0-ia32:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-ia32:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-ia32:printing-4.0-noarch

You can try with  lsb_release --all .

Which Linux brand/distribution is that?

Redhat

It should recognize -a in lsb_release. Ask them to run cat /etc/redhat-release then.

i gave nothing (empty word) as password.

Please try without user ID too. Both user ID and password should be empty.

LSB Version:    :core-4.0-amd64:core-4.0-ia32:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-ia32:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-ia32:printing-4.0-noarch

Distributor ID: RedHatEnterpriseServer

Description:    Red Hat Enterprise Linux Server release 5.6 (Tikanga)

Release:        5.6

Codename:       Tikanga

same error result with neither user id nor password passed.

Anything in logs? On either side?

client side: none. server side: same

Very strange.

Can you, please, post IBM Explorer Connection Details -> Properties tab screen shot?

Can you explain how the channel is configured - are you using CHLAUTH feature to restrict MCAUser ?

Here is an article about securing a channel:

My tool set always the MCAUser of the channel to the user id you provided, with the help of a security exit. This was introduced to support zOS RACF authentication.  Now, seems that you have a different way of securing your channel.

Can I ask you to read the article and tell me in which case you are ?

my evaluation time for your tool ends here. i will ask our mq support for a supported solution other than ibm mq explorer. thanks for your given support so far. i will return to your tool when our mq server will be upgraded to newer versions compatible with your auth.