MQ

Hi,

MQ explorer is an excellent tool for certain functions. It is easy to see the configuration of a queue manager and clusters. Manipulation of messages using MQ explorer is limited. It uses the security of the queue manage you connect to to provide authentication and authorisation so requires your admins to set up the required access correctly to provide the correct access. 

Other useful tools include 

IBM MQ Console - https://www.ibm.com/docs/en/ibm-mq/9.4.x?topic=zos-planning-use-mq-console-rest-api

MO71 (requires licence but is not very expensive) - https://www.mqgem.com/   - This might be the MQ Administrator you are not being allowed to use. It is pretty invaluable for a developer to monitor and manipulate messages. If I was you I would challenge why you are not being allowed to use it. Sounds like gatekeeping to me.

rfhutil https://github.com/ibm-messaging/mq-rfhutil

mq command line utilities - runmqsc , amsput/amqsget,  dmpmqmsg  - https://www.ibm.com/docs/en/ibm-mq/9.4.x?topic=reference-mq-control-commands

Regards,

Rab.  
  

Hi Wolfgang.  Take a look at Infrared360 (Avada Software). It was created for this exact reason.  There are 10 of 1000s of users who are not all MQ administrators using the product. 

Your users will find it productive & easy to use.  It has an innovative security structure to allow visibility and action permissions to groups/teams of end users.  It is agentless and the install is basically an unzip of the package.

Yes, IBM MQ Explorer is commonly used by developers for basic visibility and message browsing.
It's lightweight, easy to set up, and suitable for dev/test environments.
Admins often restrict its use in production due to security and control concerns.
For more advanced features, third-party tools like MQ Visual Edit or MO71 are preferred.
In many shops, it's devs = MQ Explorer, admins = advanced/custom tools.

@Wolfgang Beikircher - that's a great question with many requirements you're asking for with not many tools in the marketplace that offer a solution. We've been using Avada Software's IR360 for more than a decade with great success. The advantage the software has over MQ Explorer is it's a web-based application with RBAC for a varied user base. You have DEV that need access to see what's going on with areas of interest but you don't need them modifying the MQSC? IR360 can do that. You have ADMINS that need full control? IR360 can do that. You need dashboarding functions? Yep IR360.

On top of just a few of these great features, you get the pluses of alerting/monitoring with extensibility into SMTP or Splunk (or another tool over snmp). Plus it's not just for MQ. Have Kafka? Have API Connect? Datapower? It's a very robust tool with lots of options.

And no, I don't work for Avada Software but I collaborate with them. Their support is exceptional and their product management team knows the market because they are the market (originates from experiential requirements rather than sitting in a room thinking "what can we sell to the market").

https://avadasoftware.com/

Thanks for the input of you all. It was very helpful for me even if I was surprised that the product IBM MQ Explorer does not cover the requirements of devs and admins.

@Rab McGill exactly! That is the product our admins are using. Since the tool is not very appealing for devs, it wouldn't be a problem if we use another one. 

So I would say we give the MQ Explorer a try. It seems that our admins had concerns about the security part. They told me, that the users couldn't be authenticated by their single username but use all the same user. That sounds strange to me. Anyway, MQ Explorer as a big IBM in front. So we try the 'official tool' in the first place.

@Gregory Hanson obviously we keep the Avada-tool in mind in case the MQ Explorer isn't enough. 

Thanks for your support. I appreciate that very much!

A couple of additional comments:

MQ Explorer, as a thick client, makes for somewhat of a headache for your help desk. You also may run into issues sharing import/export files which has it's own security risks. 

IR360 is a connect once, share many through your own controls. If you integrate with LDAPs, you can abstract the hassle of keys and connections criteria to your end users. You won't need to share imports/exports as the tool, defined by a competent IR360 admin, will manage it up front and your end users will just become "power users" in the scope of work they are experts in.

Good luck on the journey and be careful about falling into the "IBM is expert so their tools must be as well" trap. While they continue to innovate and are even expanding some functionality into the MQ Web Console, they have also clearly articulated they will not be adding RBAC or alerting/monitoring into the tool.

Hi Wolfgang,

As an occasional MQ dev and MQ administrator having to manipulate and load messages M071 is an invaluable tool. I do suggest you revisit your use of it since you have paid for it already. 

MQ Explorer security is done at the queue manager. It is certainly possible to authenticate individual user id. e.g. using MQ authentication to LDAP, https://www.ibm.com/docs/en/mq-appliance/9.4.x?topic=management-user-authentication-ldap or with certificates. But this requires MQ to have been configured to use ldap as its authentication method (which I recommend). 

I also suggest you look at the MQ console it can be hooked up to ldap independently of MQ but it requires the MQ console to be installed. It is part of the MQ distribution and is free. 

Regards,

Rab.

Hi,

There's nothing wrong with using MQ Explorer, but its design is focused on being an MQ admin tool rather than a tool for developers.

You should have a look at MQ Visual Edit by Capitalware. It is an MQ tool designed for developers, testers, and support people. It does not have any MQ admin features. It runs natively on Windows, macOS (Mac OS X) and Linux PCs/laptops. It can connect to any local or remote queue manager (including z/OS). MQ Visual Edit has full language support for the following 55 languages.

Later

Roger

My organization has also been using Avada Software's IR360 for more than 12 years.  We use the IR360 software to administer our MQ objects very successfully.  The big advantage that the tool offers is auditing.  All changes to your MQ objects are fully audited.  The audit shows the before and after changes. I also agree that the Avada team provides excellent support and collaboration.  

I see you want to discourage the use of MQ Explorer by developers. :)

The fact that MQ Explorer does not support RBAC or requires integration with LDAP is problematic for us. We are operating in a highly regulated environment and need to ensure correct authentication and authorization. Obviously, we must also comply with GDPR, so access to data in a production environment must be very limited and restricted (not to mention monitored/logged, etc.).

Thank you again for your input. We will take this into consideration for the future.

Hi Wolfgang,

> The fact that MQ Explorer does not support RBAC or requires integration with LDAP is problematic for us. We are operating in a highly regulated environment and need to ensure correct authentication and authorization.

I come across that comment a lot from customers. You should never ever do authentication and authorization at the client-side (i.e. MQ Explorer). The authentication and authorization should be done at the queue manager (server-side), otherwise, end-users can circumvent the security put in place with MQ Explorer. i.e. they can use a different tool or write their own tool to manipulate the messages or MQ objects in the queue manager.

Bottom-line is that since you have GDPR requirements to meet, then implement the required authentication and authorization on your MQ z/OS queue managers and you will be good to go, no matter what client-side MQ tool you decide to give to your developers & MQ support staff.

Regards,

Roger

Hi Wolfgang,

yes, and I enabled public display access. You can see a guide I created here. It is for Linux and similar can be done on z/OS.

I also enabled browse and admin access for specific LDAP users. I believe this can be done on z/OS by setting a chlauth for the LDAP client user and setting the corresponding z/OS user as mcauser.