MO71 TLS Configuration

This blog post is going to cover how to set up TLS secured client channels when using MO71 to connect to your queue managers. Before I start, I just want to say up front that there is nothing special about how you do this. MO71 is a ‘C’ language MQI application and so setting up TLS for MO71 is just the same as setting it up for the IBM supplied ‘C’ language sample amqsputc as an example. If you know how to do that, then you know how to set it up for MO71.

MO71 TLS Connection to Queue Manager

Certificates

In order to have TLS secured connectivity between MO71 and your queue manager, your queue manager must have a certificate, hopefully not a self-signed certificate; and you, the MO71 user, must also have a certificate identifying you. It is likely that this certificate identifying you will be used for connectivity from various different tools, so it does not need to be specific to MO71. This blog post is not going to cover setting up the queue manager certificate as that has been amply covered in IBM Docs. What you need at your MO71 machine is a signed certificate identifying you, and a copy of the CA certificate that signed the queue manager’s certificate. It is possible that you have several of the latter item depending on how your queue managers are setup. One hopes that you have many less of these than the number of queue managers you need to manage.

Key Database File

MO71 is a ‘C’ language MQI application. This means that the IBM MQ Client code expects it to use a KDB file with a matching named stashed file. Unlike Java programs, you do not provide the password to the certificate store (KDB file) anywhere, the IBM MQ Client code finds the stash file that contains the password due to the fact that it has the same name as the KDB file. Here is my set of files:-

 Directory of C:\MQGem

06/07/2021  16:43                88 MQGemClient.crl
06/07/2021  16:43            20,088 MQGemClient.kdb
06/07/2021  16:43                88 MQGemClient.rdb
06/07/2021  16:43               193 MQGemClient.sth
               4 File(s)         20,457 bytes

Later you will see when configuring MO71 that you use the name up to, but not including, the file extension. The IBM MQ Client code can construct the name of the key repository and password stash file by appending the “.kdb” and “.sth” file extensions respectively.

If you don’t already have a KDB file supplied for your use, you should create one now.

Step 1: Create a KDB file

IBM MQ supplies tools for you to create the files you need. In this case we show examples of using the command line tool runmqakm. There is also a GUI tool that can do the same job. Here is the command to create your KDB file. In my example, the KDB file (and accompanying stash file etc) will be created in the C:\MQGem directory, using names MQGemClient.* – you may wish to change this. In addition, you probably want a stronger password too!

runmqakm -keydb -create -db C:\MQGem\MQGemClient.kdb -pw passw0rd -type cms -stash

If you want, you can use the runmqakm tool to create a password for you:-

runmqakm -random -create -length 16 -strong

The KDB file, once created, is the place to put the various certificates you need. As mentioned above, you’ll need to have the CA certificate that signed your queue manager(s) certificates. This is so that the certificates coming from the queue managers at connection time can be validated by the IBM MQ Client as part of the TLS handshake.

If you have one or more files containing the CA certs to allow you to validate connections to your queue manager(s), add them to your KDB now. If you only have a single certificate file (a PKCS#12 file) that also contains the CA certs, skip Step 2.

Step 2: Add CA certificates to KDB

Here is the command to add a CA certificate to your KDB. As before, you are likely using a different location in your file system for the KDB file. Note that I am using the -stashed parameter from now on, so I never have to type in the password again. The label you use when you add a CA certificate doesn’t matter. Just make it something that is helpful in remembering what this certificate is. In my example MQGemProdCA is the label I have used for the production environment CA certificate.

runmqakm -cert -add -db C:\MQGem\MQGemClient.kdb -stashed -label MQGemProdCA -file MQGemProdCA.arm -format ascii -trust enable

Finally you need to have a certificate identifying you, the user of MO71. You may have been given a file already containing your signed certificate, and have to add that to your KDB, or you may need to generate a certificate request, get it signed by your company CA, and then when you get it back, receive it into the same KDB where you created the request. Choose either Step 3a or 3b below depending on how your company does this.

DO THIS: Step 3a: Add PKCS#12 private certificate into KDB

This special certificate type is one that contains both your certificate and the private key for the certificate. It is very important to keep the private key safe, so when transporting this around in a PKCS#12 file, this particular type of file has a password. Other files that only contain certificates without private keys don’t have passwords.

Here is the command to add a PKCS#12 certificate file to your KDB. This command will also add the CA certificates that are in the file. Note that I am using the -stashed parameter for the KDB password, so I never have to type in the password again. The password on this command is the one that goes with the PKCS#12 file you have been given.

runmqakm -cert -import -file MoragCertificate.p12 -type pkcs12 -pw pkcs12passw0rd -target c:\MQGem\MQGemClient.kdb -stashed
OR THIS: Step 3b: Create a Certificate Request

To make a certificate request, issue the following command, using the KDB file that you just created.

runmqakm -certreq -create -db C:\MQGem\MQGemClient.kdb -stashed -label MQAdminProd -dn "CN=Morag Hughson,OU=Prod,O=MQGem Software" -file Clnt_Prod_Request.csr

Now send the certificate request file off to the CA that signs certificates for your environment. When you receive the signed certificate file back from them, receive it into the same KDB as before with the following command.

runmqakm -cert -receive -db C:\MQGem\MQGemClient.kdb -stashed -file Clnt_Prod_Signed.arm

As a final check that everything got added ok, list the contents of your KDB with the following command.

runmqakm -cert -list all -db C:\MQGem\MQGemClient.kdb -stashed

You should see output something like this. There should be at least one trusted certificate (shown with a !) and at least one personal certificate (shown with a -). You will need the label of the personal certificate when you come to configure MO71 in a moment, so remember that.

5724-H72 (C) Copyright IBM Corp. 1994, 2020.
Certificates found
* default, - personal, ! trusted, # secret key
!       MQGemProdCA
-       MQAdminProd

Server-connection Channel

Now that you have all the certificates put in place, you’re going to need to create a TLS-secured server-connection (SVRCONN) channel on the queue manager if you don’t already have one in place.

Step 4: Create TLS-secured SVRCONN channel

Here’s an example MQSC command to define such a channel. The name you use for your channel may well be different. Whatever it is, remember it for the next step.

Your company may choose to use a different CipherSpec (the SSLCIPH) parameter. I have chosen to use the more recently introduced ANY_TLS12. If you can’t use one of the “ANY” values then you will need to make sure that you use the same value that is in your SVRCONN when you come to configure MO71 in the next step.

DEFINE CHANNEL(MQGEM.SVRCONN.TLS) CHLTYPE(SVRCONN) TRPTYPE(TCP) SSLCIPH(ANY_TLS12) SSLCAUTH(REQUIRED)

MO71 configuration

Now you are ready to configure MO71 to connect securely to your queue manager. It is worth saying here that you can, if you want to, set up MO71 just as you would set up the IBM supplied sample amqsputc. You could create a CCDT, and use the MQSSLKEYR and MQCERTLABL environment variables.

However, here we are going to configure MO71 by filing in the various fields in the Client configuration on the Location Dialog.

If you already have a location in MO71 for this queue manager that you just need to change to use TLS now, skip Step 5 and just open up the location dialog for your existing location and click on the Configured button to get to the Client Channel dialog.

Step 5: Add Location

Choose menu File>Add Location…

In the location dialog that appears, fill in a name for the Location; the Queue Manager name; put this location in a group if you are using them; check the Client box and you will find that the Configure button is now enabled to press. Pressing it will open up the client configuration dialog.

MO71 Location Dialog

Step 6: Client Configuration Dialog

In the Client Channel Definition dialog, make sure that you have the correct channel name, you may have to change it if you previously were connecting without TLS. Ensure you have a connection name filled in if you are making a new location here. If you are altering an existing one, there should be no change required as the same listening port is used for both clear and TLS connections. Choose a Cipher Spec that either matches what you have on the queue manager SVRCONN, or uses the same protocol that is requested. I have ANY_TLS12 on the SVRCONN so I have chosen a TLS1.2 Cipher Spec. You can see which Cipher Specs use which protocol on this handy page in IBM Docs.

Once you have selected a Cipher Spec, the dialog will show you the other SSL/TLS related fields. Fill in the Key Repository remembering not to include the extension of the file as discussed earlier. And fill in the Certificate Label that you took note of earlier.

MO71 Location Dialog Client Channel

Now click on OK on this dialog and if you just created a brand new location remember to click Add on the location dialog.

Step 7: Test Connectivity

The easiest way to test your newly configured connectivity is from the Location dialog. If you just added it as a new location, you will have to reopen the location dialog by right-clicking on the queue manager in the list on the main window and choosing Open Location.

Use the Connect button first. Look in the Status bar at the bottom for any error messages and if you get an error message, use the Error Log… button to quickly bring up the client error log for more details about the error – remember to scroll to the bottom.

MO71 Location Dialog

If the Connect button changes to Disconnect and the top of the dialog now says “[Connected]” then you have successfully connected MO71 over TLS and you are good to go! From now on all TCP/IP traffic over this client connection is secure.

Summary

It is hoped that this post will help you set up TLS-secured connectivity between the MO71 program and your queue manager. Remember that the same KDB file and certificates will also work with the IBM-supplied samples such as amqsputc. If you have any issues, it may be helpful to try things out with that very simple sample first. It is also good advice if you get validation problems to change the SVRCONN channel to use SSLCAUTH(OPTIONAL) and get it working that way first. Once it does then go back to SSLCAUTH(REQUIRED) knowing that the problem is that you are either not sending, or the queue manager is not validating, the client side certificate.

There are a few considerations about multiple environments, e.g. Test vs Production, that I would like to cover, but this post is already quite long, so I will write another post about that and link it in here once complete.

If you have situations where you are trying to set up TLS-secured connectivity for MO71 that are not covered in this post, please do get in touch, either in a comment below, or through any of the usual channels (see About page).

MO71 Activity Trace Viewer – Recent Changes

MO71 has an Application Activity Trace viewer (which we wrote about before here) and we have recently made some changes to it as a result of some customer feedback. We thought we would take this opportunity to remind you that the viewer was there, and to tell you about the recent additions.

You can find the “Activity Trace…” feature in the “Action” menu. The viewer will be opened using your currently selected queue manager.

  • Change any of the options for filtering on the “Settings” tab.
  • Always remember to press the “Apply Settings” button at the bottom.
  • Switch to the “Output” tab to see the information about what your traced application has been doing.
22:35:01  21372(  1) [  231us] d:\nttools\q.exe MQCONNX 
22:35:01  21372(  1) [   43us] d:\nttools\q.exe MQOPEN Q1 
22:35:01  21372(  1) [   23us] d:\nttools\q.exe MQOPEN Q2 
22:35:01  21372(  1) [   28us] d:\nttools\q.exe MQGET Q1 RC(2080) Truncated message failed
 Sat Jun 12 22:35:01 2021
 Context
 MQGET(
    Connection Id:414D51434D5147312020202020202020B3E9C26001206725
    Hobj         :2 QUEUE(MQG1/Q1)
    MQMD
    MQGMO
    Buffer Length:2048 
    Data Length  :3428 
    CompCode     :1    
    Reason       :2080  Truncated message failed
   )
22:35:01  21372(  1) [ 2161us] d:\nttools\q.exe MQGET Q1 
22:35:01  21372(  1) [16230us] d:\nttools\q.exe MQPUT Q2 
22:35:01  21372(  1) [    6us] d:\nttools\q.exe MQGET Q1 RC(2033) No message available
22:35:01  21372(  1) [    6us] d:\nttools\q.exe MQBACK 
22:35:01  21372(  1) [    6us] d:\nttools\q.exe MQDISC 

Some example output from the MO71 Application Activity Trace viewer

You can filter the view so it only shows what you are interested in. For example, you might want to only see unsuccessful API calls, so you uncheck OK CompCodes on the “Settings” tab. However, some failing Reason Codes are not so interesting. One such failing Reason Code that is less interesting to view is MQRC_NO_MSG_AVAILABLE (2033). One of the new features added is the ability to list reason codes to be excluded from the output.

You can list reason codes to include or exclude from the Activity Trace viewer

Previously this Reason Code entry field was only for one reason code. Now it can be a list, and either a list to include, or a list to exclude.

If you are using the Activity Trace Viewer to understand the behaviour of an application, you may wish to create a report from what you have learned. Once you have filtered the viewer to show just what you want to see, and perhaps opened up some of the sections to drill down on certain API calls to look at more details, you might want to copy some or all of what you can see to add to a report.

New Context Menu

It has always been possible to select text in the “Output” tab of the Activity Trace Viewer, and use Ctrl + C to copy what you have selected. However, there are now a few additional ways to get hold of the output. A context menu (right-mouse click) has been added to the viewer, and it allows you to copy the selected text (just the same as using Ctrl + C); it also allows you to copy all the text that is shown in the viewer to the clipboard, saving you having to select it first if you want all of it.

Also, there is a new option to export the text directly to a file which might be more appropriate if you have a larger report, rather than selecting only a small section of text. When exporting the text to a file, it will output what is shown, that is the levels you have opened will have their contents shown in the file output and the contents of the levels you have left closed will not be in the file.

Activity Trace Drill down MQINQ

MO71 Activity Trace – open up levels to see more detail

You can however, select the “All Levels” checkbox on the export dialog. This essentially saves you manually opening up every single level to show the detail on all the API calls, but will of course increase the amount of data exported considerably.

Export dialog for Activity Trace output

Activity Trace is a very useful feature in IBM MQ, and the Viewer in MO71 makes it very easy to learn exactly what the data produced by MQ is telling you about your application. Why not try it out and see what you can discover about some of the applications making use of your queue manager?


The new version can be downloaded from the MO71 Download Page. Any current licensed users of MO71 can run the new version on their existing licence. If you don’t have a licence and would like to try out MO71 then send an email to support@mqgem.com and a 1-month trial licence will be sent to you.

MO71 calculating totals

In another post, we have written about how MO71 displays the total number of items you are viewing in your list. So, say you are viewing queues with a depth greater than 80% of their maximum, you’ll immediately see how many queues that is.

We were asked the following question recently:-

Might be handy to total up (and/or average) the column numeric values, e.g. the queue depth total or average for the displayed queues

Not withstanding any future features that may or may not be added to MO71, with the current version of the product you can display totals using the following method.

We start with an example from the MO71 User Guide (Chapter 5.4 “Filter Examples”) and we’ll expand on it a little. Remember you can use the Filter Manager (Ctrl + F) to make creating filters easier.

I created this filter and gave it the name StatusTotals.

if (_first)
{
  @total := 0;
  _first := false;
}
@total := @total + cur;
if (_last) status("Total messages = ",@total);
true;

Now I can use the filter on a list of local queues, by typing $StatusTotals in the filter bar, and it prints out the total message in the status bar below the list.

MO71 showing total number of messages in status bar

Now we’re going to expand on this simple filter to also display average queue depths. To do this we need to be careful about a couple of things to make this filter a bit more robust. When totalling up the number of messages we should only do so for queues of type LOCAL. When calculating the average value, which we’ve defined as a floating point variable using @@, we should be sure we have some numbers to average to avoid attempting to divide by zero.

if (_first)
{
  @total    := 0;
  @count    := 0;
  @@average := 0;
  _first    := false;
}
if (type = local)
{
  @total := @total + cur;
  @count := @count + 1;
}
if (_last)
{
  if (@count > 0)
  {
    @@average := @total/@count;
    status("From ",@count," queues: Total messages = ",@total, "; Average depth = ",@@average);
  }
  else
  {
    status("Total messages = ",@total);
  }
}
true;

MO71 showing total and average number of messages in status bar


If you don’t have a licence and would like to try out MO71 then send an email to support@mqgem.com and a 1-month trial licence will be sent to you.

Is there a way to delete a single message from an MQ queue?

IBM Support recently released a Support Doc which posed the question:-

Question

Is there a way to delete a single message from an MQ queue (arbitrary position in the queue)?

The document described a couple of options. In this post we cover how to do this using MQGem tools as several of them offer this capability. Open up the twisty for each tool to read how to do this.

Using MO71

In MO71 you can browse a list of messages on a queue, then from that list, select an individual message (or multiple messages if you need to). Then press the Delete button, or select Delete from the right-mouse button context menu and the selected message(s) will be deleted.

MO71 uses the MQ facility, get by message token, so only the exact message(s) that you select from the list will be deleted. While the position of the message on the queue is shown, this is not used for deletion and neither is Message Id, since there is no guarantee that this will be unique either. Each message on a queue is guaranteed to have a unique Message Token.

Alternatively, you can double click on a message from the list, to view the whole message individually. Then from that display, having checked all the details, and made sure it is the message you want to delete, you can press the Delete button, or select Delete from the context menu.

Take care when deleting messages from a production queue manager. Consider that it might be safer to Move the message(s) to a separate holding queue, just in case the message proves to be important after all. MO71 makes it simple to Move messages too. Just fill in the holding queue name, and then press the Move, rather than Delete, button.

Using the Q program

To delete a single message from an MQ queue using the Q program, you should first discover the message ID of the message you wish to delete, to ensure you are addressing the correct message that you intend to delete. Do this by displaying the messages on the queue like this:-

q -m MQG1 -i Q1 -dd

This will browse (-i) the messages on the queue and display the MQMD after the MQGET (-dd) allowing you to see the Message ID of each message on the queue. You will see output like this for each message:-

==============================================================
----- MQMD after MQGET -----
[  324 bytes] Message Descriptor (MQMD)
Report       :00000000
Message Type :8 (Datagram)
Format       :'MQSTR   ' (String)
Priority     :0 (Lowest)
Persistence  :0 (Not Persistent)
Message Id   :414D51204D514731202020202020202099FA4A6020B74B02
              A M Q   M Q G 1                 . ú J `   · K .
ReplyToQ     :'                                                '
ReplyToQMgr  :'MQG1                                            '

Now you can copy that message ID and use it on another invocation of the Q program to delete that specific message from the queue.

q -m MQG1 -IQ1 -gxm:414D51204D514731202020202020202099FA4A6020B74B02

Bear in mind that message IDs are likely to be unique, but this is not guaranteed. It would be safer to move the messages to a separate queue, before deletion. This is simple to achieve using a command like the following:

q -m MQG1 -IQ1 -o HOLDING.Q 
-gxm:414D51204D514731202020202020202099FA4A6020B74B02
Using QLOAD

If you have already browsed the queue contents and output them to a file, you can find the message Id of the specific message you are attempting to address by looking for the Message Descriptor attribute “MSI”. Here is a snippet from a QLOAD file to show an example.

A FMT MQSTR
A PRI 0
A PER 0
A MSI 414D51204D514731202020202020202099FA4A6020B74B02
A COI 000000000000000000000000000000000000000000000000

Now you can copy that message ID and use it on another invocation of the QLOAD program to delete that specific message from the queue. We would recommend using QLOAD to actually move that message to an output file, in case you change your mind about deleting it!

qload -m MQG1 -IQ1 -f c:\temp\deletedmsg.qld 
-gxm414D51204D514731202020202020202099FA4A6020B74B02

Alternatively, you can use the very flexible search and filtering capabilities of QLOAD to narrow down your search of messages on the queue until you find the one you wish to delete, and then offload it to a file, or delete it entirely.

For example, this invocation removes all messages on a queue that are older than one week, and moves them instead to the named file:-

qload -m MQG1 -I Q1 -T7:0:0 -f c:\temp\oldmsgs.qld

Another example, here we remove messages larger than 1MB from a queue:-

qload -m MQG1 -I Q1 -z 1M -f c:\temp\bigmsgs.qld

A third example, here we remove message containing the string “Acme Limited”:-

qload -m MQG1 -I Q1 -s "Acme Limited" -f c:\temp\acmemsgs.qld
Using MQEdit

In MQEdit you can browse a list of messages on a queue, then from that list, select an individual message (or multiple messages if you need to). Then press the Delete button, or select Delete from the right-mouse button context menu.

MQEdit uses the MQ facility, get by message token, so only the exact message that you select from the list will be deleted. While the position of the message on the queue is shown, this is not used for deletion and neither is Message Id, since there is no guarantee that this will be unique either. Each message on a queue is guaranteed to have a unique Message Token.

Alternatively, you can double click on a message from the list, to view the whole message individually in the pane below, and then from that pane, having checked all the details, and made sure it is the message you want to delete, you can select “Delete Message” from the context menu.

Particularly for production queue managers, we would always suggest that it is safer to move message(s) to a holding queue rather than deleting them immediately. In MQEdit it is very simple to move a message between queues, all you need do is drag and drop the required message(s) from one queue to another. You can even copy and move messages between queue managers this way.


If you don’t have any of these tools, but would like to try any or all of them out, please contact support@mqgem.com and a 1-month trial licence will be sent to you with no obligation to buy. You can download the tools from our website.

MO71 Web Access Navigation Links

MO71 provides a web interface view into your IBM MQ Queue Managers and their objects and status. The default set of HTML files we supply with MO71 have a navigation pane on the left-hand side of your browser window and the data that you choose to look at, say a list of channels, gets shown to the right. The look and feel of the web pages are highly configurable. In these examples, we show screenshots of an alternate set of webpages we made for a fictitious mining company that we used in the video introducing MO71’s Web Access. These garish colours just illustrate that you can make it look any way you wish.

An MO71 Web access browser showing the Navigation Pane on Left

It’s this navigation pane that has had a recent enhancement and which will be covered in this blog post.

The default set of links

Before this change, you could control the links that were inside the twisty for each queue manager to a certain extent. You could configure which object types you wanted links for, and these would then be automatically generated. The downside of these links was that they showed every object of that type in the list. There was no opportunity to configure them, add filters, or object types to reduce the size of the initial list of objects you were presented with. The screenshot to the left illustrates the default set of links that were generated when your HTML file included the MO71 %[qmlist] insert as follows:-

%[qmlist MQG*: grp : def : linkhtml=(target="dataframe")]

If you wanted a specific set of links, you could replace the default set (identifier ‘def’) with a list of the identifiers that you wanted. For example, in this next command, the links would be Channels, Channel Status, Queues, Processes, and Namelists.

%[qmlist MQG*: grp : chl,chs,q,prc,nl: linkhtml=(target="dataframe")]

With this latest enhancement you can now create literally any links you want to put into this list. To do so, you create a small HTML file, mylinks.html in this example, to contain the snippet of HTML to go inside the twisty, and then code your qmlist statement as follows (note you don’t include the .html file extension:-

%[qmlist MQG*: grp : file=mylinks : linkhtml=(target="dataframe")]

You can put any links you want in this file, and if your links need the queue manager name as part of them then you code the %[qm] insert at that point. Here’s an example of a few links you might consider using.

<a href="https://www.MiningCo.com/qmgrcontacts/%[qm].html" target="dataframe">QMgr Contacts</a><br>
<a href="/mq/admin/msgs/%[qm]/SYSTEM.DEAD.LETTER.QUEUE" target="dataframe">DLQ Messages</a><br>
<a href="/mq/admin/chstatuses/%[qm]?filter=&quot;status=retrying&quot;" target="dataframe">Channel Status</a><br>
<a href="/mq/admin/authrecs/%[qm]?objtype=queue" target="dataframe">Queue Auth Recs</a><br>
<a href="/mq/admin/events/%[qm]?evreason=command" target="dataframe">Command Events</a><br>
<a href="/mq/admin/queues/%[qm]?type=qlocal;filter=&quot;!(queue==&quot;SYSTEM.*&quot;)&quot;" target="dataframe">Our Queues</a><br>

This selection of links illustrates that:-

  • The links don’t have to be MO71 links at all. If you have links that are specific to the queue manager and the URL contains the queue manager name, you can build the link using the %[qm] insert
  • You can have a message list as one of the links. This wasn’t possible before because you needed a queue name to build the link
  • You can have links with filters on them. This one only shows retrying channels
  • You can use lists that are reduced by object type or indeed any type
  • In fact you can use lists that are reduced by any keyword on the command. Here’s the MQEV event list reduced to show only command events
  • You can also combine keywords and filters

In short any link, an MO71 link or an outside link, can be put into this HTML snippet file, and used to build your navigation links.

In addition, this HTML snippet file can be combined with the original identifiers, so you can have your list as well as so of the original links if you want, for example:-

%[qmlist MQG*: grp : chl,chs,q,prc,nl,file=mylinks : linkhtml=(target="dataframe")]

Have a go and see what you think.


The new version can be downloaded from the MO71 Download Page. Any current licensed users of MO71 can run the new version on their existing licence. If you don’t have a licence and would like to try out MO71 then send an email to support@mqgem.com and a 1-month trial licence will be sent to you.

MO71 version 9.2.2 is released

MQGem Software is pleased to announce that a new version of MO71, our GUI Administrative tool for IBM MQ, is now available.

The main features of the release are as follows:-

Addition of HTTPS to Web Access

A number of you have asked for this feature, so now the MO71 Web Server can be configured to use HTTPS. Configure the location of the Microsoft certificate store that contains a certificate to identify the MO71 web Server, preferably with a Subject Alternative Name extension matching your server DNS name so that browsers don’t complain, and start it up.

Configuration of the MO71 HTTPS Web Server

Now your MO71 generated web pages can be served up over an HTTPS secured transport.

Your MO71 generated webpages can now be served up over HTTPS

Updates to the HTTP Connections List

Related to the above feature, the HTTP connections List has been updated to show some additional fields.

When using HTTPS you can see the protocol (e.g. TLS 1.2), the encryption algorithm (e.g. AES256) and the signing algorithm (e.g. SHA384) that were negotiated for the connection from the browser to use.

For all connections (HTTP or HTTPS) the User Agent field is available. This is field that identifies the browser making the connection.

Details of the connections made to the MO71 Web Server

Support for DISPLAY CFSTATUS added

List, and individual record dialogs, as well as web access support, and usage tailoring support have been added for the DISPLAY CFSTATUS command.

An example CFStruct Summary Status dialog

New options to automatically fold Userid and Password fields to uppercase

This is another customer requested feature also added in MQEdit in it’s most recent release. You can select either or both of your Userid and Password fields for a location be folded to uppercase. Note that when selected, the dialog where you type in your password will remind you that you have these settings on. This can be especially useful for z/OS TSO logins where it can be easy to forget that you have an upper case password because the TSO login panel always folds it to upper case for you.

MO71 Location Dialog – Upper Case of Userid and Password

Blank columns in CSV exported data

When exporting MO71 dialog lists, normally if a column is completely empty, it is not shown on the list dialog, and it is not exported either. This feature adds an over-ride so that if you are exporting to CSV, you can request that empty columns ARE included.


The new version can be downloaded from the MO71 Download Page. Any current licensed users of MO71 can run the new version on their existing licence. If you don’t have a licence and would like to try out MO71 then send an email to support@mqgem.com and a 1-month trial licence will be sent to you.

Example MO71 filter – Expiring Certificates

Tim Zielke recently wrote a blog post with a marvellous idea for keeping track of all the certificates that affect your environment. In short, he put useful additional information into the CHLAUTH description field of each rule that allowed a channel using a certificate to connect to his queue manager. That information was the expiration date of the certificate. This gave two immediate benefits.

  • It is easy to see when certificates have expired, and when CHLAUTH rules are written to include serial numbers, this allows the rule to be cleaned up because it is now no longer necessary.
  • It is also easy to determine whether there will soon be some problems as a result of certificates expiring, with new CHLAUTH rules being needed to be put in place, especially when serial numbers are included in the rule. All the information is on one display, instead of being scattered about in various different places.

You can read his whole blog post here.

This got me thinking about MO71 filters. Having put the information into the description field of the CHLAUTH rules as Tim suggests, a filter could highlight those records that were problematic (i.e. expired) or soon to be so.

Here is the filter I wrote.

@offset:= findstr(descr,"Expires=");
if (@offset > 0)
{
  @$date:=substr$(descr,@offset+8,10);
  @exptime:=mqtime(@$date,"00:00:00");
  @ttl:=(@exptime - _time)/86400;
  bg(@ttl<=0,red);
  bg(@ttl>0 AND @ttl<7,yellow);
  usrcol("Time to Live", @ttl,text+left);
}
true
  1. This filter finds the text in the Description field “Expires=”
  2. If present it takes the next 10 characters to be a date.
  3. It passes this date, along with midnight as the time, into the MO71 built-in filter function mqtime() to get the expiry time in seconds.
  4. The time-to-live (TTL), that is the remaining life of the certificate before it expires, is calculated as the difference between the date in seconds and the time now, using the MO71 built-in system variable _time. This TTL is then adjusted to days instead of seconds.
  5. We then set the background colour based on whether it has already expired, coloured red, or whether it will expire in the next 7 days, coloured yellow.
  6. Finally we put this TTL variable value into a user column because that way we can sort the whole list by that column if we need to.

Here’s a screenshot of the filter in operation. For the purposes of screenshot brevity, I have omitted serial numbers as Tim uses in his blog post since they are not needed to illustrate this filter.

Use a filter to colour different rows of interest


If you’re not familiar with filters in MO71, they are a very powerful tool for helping you show exactly what you need to see on your MQ displays. You can watch a video about them here.


If you don’t have a licence and would like to try out MO71 then send an email to support@mqgem.com and a 1-month trial licence will be sent to you.

MO71 and referenced objects

There are lots of places in IBM MQ objects where other objects are named. As few examples include:-

  • A local queue name in the transmission queue field of a channel
  • An authentication information object named in the Connection Authentication field of the queue manager
  • A topic object in a subscription
  • A connection ID in when viewing subscription status

When you view such objects with MO71, you can interact with these fields by double-clicking on them.

Viewing already existing objects

If you are viewing an individual object dialog that refers to another object, double clicking on that field will open up another individual object dialog to show the referenced object. It’s just a simple action, but very handy, and will save you time when looking at inter-connected objects or status.

Double click on the Connection Authentication field to view the referenced object

Double-click setting for Queues

This double-click action pays attention to the preference “Double click should browse on queue lists”. If you have this preference checked, then you should hold down the Alt key to get the alternate action which is to display the object definition.

Creating new objects

Another time when this feature of MO71 really comes in handy is when you are defining new objects and their referenced objects. For example, when defining a sender channel and its transmission queue.

Imagine you are part-way through defining the sender channel, and you get to the field where you need to put the transmission queue name. You realise that you haven’t yet defined the transmission queue. Rather than going and starting up a queue dialog and defining it, you can instead type in the name you want the transmission queue to have, and then double click on that field. Again, this is just a simple action, but it saves you time.

MO71 will open up an individual dialog for that queue name, but it doesn’t exist yet.

Double clicking on the transmission queue name brings up queue dialog even if it doesn’t exist

The dialog will have the name filled in, and you can now go ahead and populate the rest of the fields for the transmission queue. Once done, you can press Create on the queue dialog and then go back to the channel dialog, and when you’re finished press Create on that one too.

Press Create on each dialog to create the objects

In the Web Interface

The same inter-connections can also be seen when using the MO71 Web Interface. Referenced objects named inside objects or status, become hyperlinks, so you can click on them to view the details about the referenced object in a web page. In the screenshot below, I’ve open the hyperlink in a new tab to make it clear what happens, but if you just click on it, it will open in place.

In the web interface, referenced objects become hyperlinks


If you don’t have a licence and would like to try out MO71 then send an email to support@mqgem.com and a 1-month trial licence will be sent to you.

MO71 version 9.2.1 is released

Hot on the heels of MO71 V9.2.0, MQGem Software is pleased to announce that a new mini release of MO71, our GUI Administrative tool for IBM MQ, is now available.

This release was created to deliver three features requested by customers, which are as follows:-

Change the value of a field for many locations at once

If you have lots of queue managers, and you need to change something in the location definition for a number of them, this new dialog can make your life much easier. You can now change values in multiple location definitions at once. For example, if you want to organise your queue managers into various “groupings”, you can make use of network names. Read this post for more about that. To set up network names by editing individual location definitions one by one would take some time, so now you can easily do it with the “Change Multiple Locations” feature of MO71.

Open the dialog from the MO71 File menu; select the queue managers to be changed in the left hand list; choose the field to be updated in the right hand list; type in the new value in the entry box and press Set New Value.

MO71 – Change Multiple Locations dialog, showing Network names

Network names is actually a comma-separated list of names, so not only can you set the entire field, you can add or remove individual items from the comma-separated list using the Add and Remove buttons.

There are quite a number of fields in the location dialog that you might find it helpful to update many at once. Take a look to see if any of those provided would be helpful to you.

Set locations to be members of the same security group

Do you have queue managers using user IDs and passwords? Are a number of them in the same security domain, for example, you have AD set up; or multiple z/OS queue managers in the same RACF; or you are using LDAP for your authentication? To save you having to make lots of changes each time you set up a new password on one of these domains, MO71 now has the concept of a security group. You can indicate queue managers are members of the same security group in their location and then when you change the password of one member of the security group, all other members get that update too. This saves you having to provide the new password on every queue manager on password change day.

This security group is just a name for MO71, it doesn’t have to match the domain, or group name or anything defined in a security repository. It is simply a grouping to tell MO71 that these queue managers all use the same user id and password at connection time.

MO71 Location Dialog – Security Group settings

The description is optional, but if provided will be used in the password prompt box that is displayed when you connect to a queue manager, or press the Set Password button, as shown in the screenshot above.

In order to initially set up the security group each queue manager is in, you can also use the “Change Multiple Locations” dialog described above.

Set CCDT imported location as MVS

You can import locations into MO71 from a number of sources (see these posts for more details). In the case of importing from CCDTs (either binary or JSON format) there is no information in the source file to indicate if a queue manager is MVS or not. However, you can now manually indicate, at import time, that the queue managers being added should be marked as MVS.

Import CCDT Dialog – choose your queue managers


The new version can be downloaded from the MO71 Download Page. Any current licensed users of MO71 can run the new version on their existing licence. If you don’t have a licence and would like to try out MO71 then send an email to support@mqgem.com and a 1-month trial licence will be sent to you.

MO71 version 9.2.0 is released

MQGem Software is pleased to announce that a new version of MO71, our GUI Administrative tool for IBM MQ, is now available.

The main features of the release are as follows:-

Graphing

MO71 has had the ability to graph numeric data from your queue manager for many releases. You could graph the depths of queues, for example. This graphing feature of MO71 has been improved with many new features, and additionally you can now also graph MQEV data in the same way.

New graphing features include:

  • Column Stacks
  • Long and Short Average lines
  • Saving of graphing defaults
  • Saving of line defaults
  • Drag resize
  • Improved time labels added to graphs
  • Auto-range of axes
  • Column relative sizing and overlap
  • Pie chart labels

This slideshow requires JavaScript.

Improvements to MO71 Web Access

Several improvements have been made to the web access feature in MO71.

  • MQEV objects
    MQEV objects and status can now be shown on the web access interface.
    View MQEV events through the MO71 web interface
  • HTML5 templates
    The template HTML files that are provided with MO71 now use HTML5, and the “twisties” generated by MO71 in the navigation area, now use HTML5 <details> and <summary> tags, so now there is no need for JavaScript for them.
  • New dialog list combinations in qmlist[]
    When you build your navigation section, you can choose which commands you want to see shown there. There are some new options now, including “all”, “allmq” and “allev”.

    <h2>Queue Managers</h2>
    %[qmlist : grp : allmq : linkhtml=(target="dataframe")]

Import from JSON CCDT file

You can seed your MO71 location definitions by importing data from a CCDT, an MQ Explorer exported config, locally defined queue managers, another MO71 config file, and now a JSON CCDT file.

More information on a Queue Manager list dialog

Information from the location definition can now be displayed on the queue manager list dialog. This includes fields that are part of connecting to the queue manager, such as channel name, connection name and user id; and also fields that help you sort and group your queue managers, group and network names.

Set Default Lists – now grouped

The menu for all the Set Default Lists dialogs was getting pretty long, so it has now been grouped up. If you’ve never used Default Lists, read this post to learn more about them and what they are for.

Service Objects can be compared

MO71 can compare the definitions of many objects types. Service objects are now one of the types that can be compared.


The new version can be downloaded from the MO71 Download Page. Any current licensed users of MO71 can run the new version on their existing licence. If you don’t have a licence and would like to try out MO71 then send an email to support@mqgem.com and a 1-month trial licence will be sent to you.