What’s in Command Levels 91x

MQ91x StairsIBM MQ released Long Term Support release V9.1.0 back in July 2018 which had a Command Level of 910. The subsequent Continuous Delivery release V9.1.1 introduced its own Command Level 911.

This post captures the changes that are available in Command Level 911.

Release Command Level Features protected by Command Level – details below
V9.1.0 910 This command level rolled up all the changes in the prior Continuous Delivery releases detailed in What’s in Command Levels 90x.
V9.1.1 911 Simpler TLS CipherSpec selection
Scripting enhancements for stateful objects

Simpler TLS CipherSpec selection

An additional value has been designed for the channel SSLCIPH field to allow the selection of a group of Cipher Specs instead of just selecting an individual one. In addition, the SECPROT attribute I wrote about in Know your protocol has been extended to IBM MQ for z/OS. Mark Wilson has written about this in an IBM Messaging Blog Post: Allow IBM MQ channels to use ANY_TLS12.

Channel Object

Updated attribute MQSC name
See DEFINE CHANNEL
Look for KC 911 indicator
PCF constant and values
See Change, Copy, and Create Channel
Look for KC 911 indicator
SSL Cipher Spec

SSLCIPH

MQCACH_SSL_CIPHER_SPEC (3544)

  • String of length MQ_SSL_CIPHER_SPEC_LENGTH (32), new possible value “ANY_TLS12”

Channel Status

New attribute MQSC name
See DISPLAY CHSTATUS
Look for KC 911 indicator
PCF constant and values
See Inquire Channel Status
Look for KC 911 indicator
SSL Cipher Spec

SSLCIPH

MQCACH_SSL_CIPHER_SPEC (3544)

  • String of length MQ_SSL_CIPHER_SPEC_LENGTH (32) showing Cipher Spec in use
Security Protocol

SECPROT

  • NONE
  • SSLV3
  • TLSV1
  • TLSV12

MQIACH_SECURITY_PROTOCOL (1645)

  • MQSECPROT_NONE (0)
  • MQSECPROT_SSLV30 (1)
  • MQSECPROT_TLSV10 (2)
  • MQSECPROT_TLSV12 (4)

Scripting enhancements for stateful objects

Various IBM MQ objects have state associated with them, for example channels or listeners, and when running commands in a script to start such objects, it can be complicated by the failures that occur when the object is already in the state you want. You didn’t want your script to fail just because the listener is already started, you wanted it to carry on. Command level 911 adds a keyword to help with such scripts.

Start and Stop Channel/Listener/Service

New attribute MQSC name
See START and STOP CHANNEL
See START and STOP LISTENER
See START and STOP SERVICE
Look for KC 911 indicator
PCF constant and values
See Start and Stop Channel
See Start and Stop Listener
See Start and Stop Service
Look for KC 911 indicator
Ignore State

IGNSTATE

  • NO
  • YES

MQIACF_IGNORE_STATE (1423)

  • MQIS_NO (0)
  • MQIS_YES (1)
Advertisements

I can haz error logs?

IBM MQ on IBM Cloud has now reached the Beta phase. See Jen’s latest Blog Post: MQ on IBM Cloud – we’ve hit beta and one of the new things in the beta is the ability to view your queue manager’s error logs.

I Can Haz Error LogsThis is a very important step since one of the first things you should learn is how to discover what your queue manager is trying to tell you when there is an error. In fact this is one of the most important things my MQ training modules also teach you.

Here’s a quick summary of exactly how you can view your IBM Cloud queue manager error logs.

Having created your queue manager, as per Woz Arshad’s YouTube video:

YouTube Introducing MQ on IBM Cloud

you can view your queue manager and get connection information on how to connect to it. From this same view you can also get hold of your queue manager’s error log. Select the “Logs and diagnostics” option.

IBM Cloud MQ Logs and Diagnostics

Select the Logs and diagnostics section

This will show a panel where you have two choices. You can download a smaller zip file which is mainly about obtaining your error logs, or you can go for the full RAS package. For just the error logs click on the “Collect logs” button, and you will then be prompted to supply a password which you will use to unlock the error log files in the zip you download.

IBM Cloud MQ Collect logs

Press the button to collect the queue manager error logs

IBM Cloud MQ Download Log file zip

Download your password protected zip file

After a few moments your zip file will be ready and then you can download it to view the contents.

Inside the zip file there will be three folders:-

  • FDCs
  • QM Logs
  • trace

You’ll be interested in the folder called “QM Logs”. N.B. This is the error logs from the queue manager not the transactional logs.

Inside that folder you will find three files AMQERR0n.LOG – usually you will find all you need in AMQERR01.LOG.

Import queue managers from an MQ Explorer export

In a recent update to MO71 V9.0.4 a new feature was added to allow you to import queue manager location information from an MQ Explorer export file.

MQ Explorer Export menu

The menu option to export MQ Explorer settings

To export your configuration from MQ Explorer, right-click on the top level folder in the left-hand navigation pane, and choose Export MQ Explorer Settings…

This will bring up a dialog for Export. Press Next on the first panel, then on the second panel you can indicate where you want the XML file to be written and what you want to be exported. MO71 will only import the Sets and Remote queue manager information, but will not complain if there is other information in the XML file, so you can go ahead and export it all if you wish.

MO71 doesn’t import local queue managers from an MQ Explorer export file since you can import local queue managers directly in MO71 as discussed in an earlier post.

MO71 Import MQ Explorer Menu

The menu to import queue managers

Once you have your exported XML file from MQ Explorer, you can drive the import from the MO71 File menu, which then brings up a dialog.

In this dialog, navigate to the location where you exported your MQ Explorer settings and click on Read MQ Explorer XML File.

MO71 Import MQ Explorer Dialog

Import MQ Explorer Locations Dialog – choose your queue managers

The list below will show all the queue managers that were found in the MQ Explorer XML file. If any of the found queue managers are already locations in MO71, the Explorer entry will have a ‘no entry’ symbol beside it showing it cannot be added again. You can click on any others to indicate you wish to import them and the red cross will change to a green tick.

If you were using Sets to group your queue managers in MQ Explorer, you can choose to have those associations imported into MO71 as well. MO71 has several grouping concepts (as described in Can you see your QMgr for the trees?). A queue manager can be in a single group on the main window, and it can be in multiple Networks, which are used in various places where queue managers are listed in MO71. Since a queue manager could be in multiple MQ Explorer Sets, you can choose whether to translate this part of the configuration into Network names or the first one into a QM Group, or both.

Once you have selected all the ones you want, click on Import, and you’re done.

And of course, just as with imported local queue managers, and queue managers imported from a CCDT file, you can edit the imported ones after the locations are created to change the location labels and any other settings.


The new version can be downloaded from the MO71 Download Page. 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.

Migrating a Queue Manager?

If you’re planning to migrate a queue manager, from one machine to another, or perhaps you’re consolidating some queue managers onto an MQ Appliance, you are probably aware of, and have even become familiar with, the steps required to export your object definitions and recreate them on the new queue manager. There are a number of tools available that can do this for you – including those from MQGem.

What about your messages though?

While it’s generally a good idea to reduce the load, and drain off as many messages as you can prior to migrating a queue manager. For example if it’s in a cluster, suspend it from the cluster before the move, to reduce the number of messages heading its way. Let all the applications drain the queues of messages and so on. However, it’s not always possible to drain every last message from all your queues.

QLOAD Offload all queuesIn the latest version of QLOAD, V9.0.1, there’s a new feature that will help out when migrating a queue manager. It allows you to unload the messages from all your queues, with one command. And then you can load the messages onto the queues on another queue manager, with one command (or piecemeal if you prefer). You would combine this with your favoured object definition export tool, and before loading the messages, you’d first recreate the queues on the new queue manager with the exported commands.

Here’s an example of QLOAD unloading all the queues on my queue manager.

qload -m MQG1 -i* -f*

The command will produce the following output to show what has been unloaded. Using the -i (lower case) flag means that the messages are only browsed on the queues and are not destructively removed.

APP1.INPUT                                           2  Done.
APP1.RESULT                                         10  Done.
APP2.INPUT                                           1  Done.
APP2.RESULT                                          4  Done.
Q1                                                  28  Done.
Q2                                                  42  Done.
SYSTEM.ADMIN.QMGR.EVENT                              7  Done.
SYSTEM.AUTH.DATA.QUEUE                             126  Done.
SYSTEM.CHANNEL.SYNCQ                                 3  Done.
SYSTEM.CHLAUTH.DATA.QUEUE                            5  Done.
SYSTEM.CLUSTER.REPOSITORY.QUEUE                      3  Done.
SYSTEM.DURABLE.SUBSCRIBER.QUEUE                      1  Done.
SYSTEM.HIERARCHY.STATE                               2  Done.
SYSTEM.INTER.QMGR.FANREQ                             1  Done.
SYSTEM.RETAINED.PUB.QUEUE                            2  Done.
WORK.REQUEST                                         7  Done.

Total : 7 Queues, 94 Messages
 plus : 9 System Queues, 150 Messages

Listing the directory where I ran the qload command, I can now see I have a file for each queue, with an extension .qld. If you prefer to have a different extension then you can alter the command accordingly. For example, use -f*.txt.

I can copy these files to another machine, or simply use a client connection to the other machine accordingly. Then I can run the following QLOAD command to load the messages onto the new queue manager.

qload -m MQG1 -o* -f*

QLOAD will make some checks when you run a load for multiple queues in this way. It will check that all the queues exist that it has files for in the directory matching the file pattern you specified (which assumes an extension of .qld if you just use ‘*’), and it will check that all those queues are empty. If it finds any problems it will report as follows:-

APP1.RESULT                            RC(2085) Unknown object name.
APP2.RESULT                            Not empty.

There are potential problems with these queues.
Are you sure you want to continue?

This lets you know to go and define the missing queues if you need them – there are messages to go onto them so the assumption is that you do need them. It also warns you of non-empty queues. Now if you’ve already started using this queue manager, you might be expecting this situation, but otherwise, you should rectify it, and then re-run QLOAD.

APP1.INPUT                                       2     Done.
APP1.RESULT                                      10    Done.
APP2.INPUT                                       1     Done.
APP2.RESULT                                      4     Done.
Q1                                               28    Done.
Q2                                               42    Done.
WORK.REQUEST                                     7     Done.

Total : 7 Queues, 94 Messages

You’ll notice that this output does not mention the SYSTEM queues that were offloaded. A generic upload will not upload most SYSTEM queues.
SYSTEM.CLUSTER.TRANSMIT.QUEUE and SYSTEM.DEAD.LETTER.QUEUE are the exceptions. The messages were unloaded to files though, so if you really need to load them you can do so the traditional way, by specifying the full queue name on the command and not using the generic upload.


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