Behaviour changes in MQ V9.0.4 – CONNAUTH/CHLAUTH

UserID and PasswordIBM recently released it’s latest Continuous Delivery release (MQ V9.0.4). This has made some changes to the default behaviours for CONNAUTH and CHLAUTH. You can read all the new changes in V9.0.4 here, but I wanted to highlight a few I thought were very important.

Adopt Context is YES by default

From the introduction of Connection Authentication in IBM MQ V8, the default value of ADOPTCTX was NO. I am delighted to see that the default has now been changed to YES. This is probably the most common configuration problem we help customers with around the use of Connection Authentication. It’ll take a while to percolate through, because there are plenty of existing queue managers out there with ADOPTCTX(NO) but it will definitely improve things.

qm.ini ChlauthEarlyAdopt=Y is now the default

The qm.ini ChlauthEarlyAdopt attribute was added in IBM MQ V8 FixPack 5 to allow users to revert the behaviour back to the way it was prior to another change that was made – i.e. back to the designed IBM MQ V8 GA behaviour. I am very happy to see that IBM has now reverted this behaviour to be there by default for everyone.

Java clients use user ID and password in the same way as ‘C’ clients

Due to the historical use by the Java client of the FAP flow to send a user ID and password (as described in this blog post) a compatibility setting had to be provided at MQ V8 GA in case any Java Client connections into queue managers were relying on this behaviour for their security exits. This meant that Java clients and ‘C’ Clients operated differently by default. Now, as of V9.0.4, the Java client uses the MQCSP to send its user ID and password just as the ‘C’ client does and they both work the same way. This is very good news.

Advertisements

How to activity trace the MO71 application

MO71 utilises the MQCNO_ACTIVITY_TRACE_DISABLED option so that while using it to view activity trace records, you are not also generating even more! This is of course, only honoured if the queue manager allows it which is controlled by the queue manager attribute ACTVCONO. So in addition, the MO71 Activity trace viewer also has some quick check boxes to hide from view all its records should they be generated.

Inspect MO71What if you want to see the activity trace for MO71 though? For example if you want to trace the API Exerciser?

There are two ways to over-ride the use of MQCNO_ACTIVITY_TRACE_DISABLED. One is to use the following command (which applies the over-ride to all applications that have specified it).

ALTER QMGR ACTVCONO(DISABLED)

The other is to add a stanza like the following to your queue manager’s mqat.ini file. Remember if MO71 is already connected, you can make an alteration to the queue manager object to get it to pick up the new mqat.ini file or just disconnect and reconnect to the queue manager to pick it up.

# Turn on tracing for MO71
ApplicationTrace:
  ApplName=mqmonntp.exe
  Trace=ON

Now looking at the Activity Trace window, on the “Settings” tab, uncheck “Exclude this process” so you can see records from this process ID, and also “Exclude MO71 processes” which just causes the filtering for the “Output” tab to hide any records that come from any “mqmonntp.exe”. Remember to press Apply Settings once you’ve made these and any other filtering changes.

Activity Trace Settings Exclude Checkboxes

Activity Trace Settings Page – Check boxes to exclude MO71 trace records

Note: With these two check boxes, you could run one instance of MO71 to view the Activity Trace records, and a second instance of MO71 doing the activity you want to trace, for example using the API Exerciser, then you could leave “Exclude this process” checked and only uncheck “Exclude MO71 processes”.

It may also be wise to turn off any automatic operations that are being done by MO71, such as exporting objects on a scheduled time interval, which would generate a lot of activity from MO71 in the trace.

Then you’ll be able to see any API calls made by the MO71 application, for example:-

13:38:35   8220( 21) [   85us] C:\MQGem\mqmonntp.exe MQOPEN INPUT.Q 
MQOPEN(
   Connection Id:414D51434D514731202020202020202027E1F55920005205
   Hobj         :8 QUEUE(MQG1/INPUT.Q)
   Open Options :00000010
                 00000010 MQOO_OUTPUT                    (Output)
   Dynamic Queue:AMQ.*
   CompCode     :0    
   Reason       :0     OK.
  )

Other resources that you may find useful about Activity Tracing.

IBM MQ and MQ Appliance News – October 2017

On Tuesday October 24th, IBM Hursley announced the next in the series of Continuous Delivery releases for IBM MQ V9.0 and the MQ Appliance. IBM MQ V9.0.4 was made available on November 6th.

Here are the various announcement letters:-

Links of interest:-


We’ll collect up any other links about the new release as we find them and put them all here.

Configuring List Dialogs in MO71

MO71 is our graphical administration tool for IBM MQ. You can manage all the different object types in MQ using its lists and object dialogs. The lists are fully flexible allowing you to determine which fields are interesting to you and which are not and choosing only to display those columns in the list as a result.

You can make these changes temporarily, just to the instance of the dialog you are currently using. You can make them more permanently, so that every time you bring up that list on that queue manager, you have the same columns. Or finally, you can make these changes across all your queue managers, because the columns you want are the ones you think should be the default set. You can also change the columns in a dynamic manner using filters.

This post will cover these various different mechanisms.

Temporarily alter the list shown

When looking at a list of objects you can change the columns that are displayed by selecting the Options -> Alter List… item from the context menu.

MO71 Alter List Menu

This will bring up a dialog where you can locate the additional columns you want to display. So I’ve got a list of queues, with some cluster queues and I want to see the Cluster Queue Manager that hosts the cluster queues, so I locate the field Cluster Queue Manager Name (CLUSQMGR) in the right hand side of the window in the list of “Remaining Fields”, and move it to the “List Contents” by pressing the  <<  button. Then I can move its position in the columns on the left hand side using the up and down buttons, and press   OK   to complete the change.

MO71 Change Queue List attributes

Now you’ll see that your queue list has the additional column you selected. However, if you close the queue list dialog, and later open another queue list dialog, you’ll see that your alteration to the list of fields shown has been forgotten, it was a temporary change that you made.

Permanently alter the list for one queue manager

Following exactly the same process as above, with one small change, you can make the change permanent for that queue manager. On the dialog which allows you to change the columns shown, instead of just pressing   OK   to make the change, first press Apply All which applies the change to all instances of that particular list dialog for this queue manager, both those currently open, and any future invocations of that list dialog. This change is also remembered across a restart of the MO71 program.

MO71 Change Queue List attributes Apply All

Permanently alter the list for all queue managers

In essence, this mechanism is changing the defaults for list dialogs. If you add a new queue manager to MO71, it will pick up the default columns too.

Using the menu option View -> Set Default Lists -> Queue List… (or whichever list dialog you want to change), you will be presented with a very similar dialog to the one above, except instead of referring to a single queue manager in the window title, it will indicate that it is a “global” list.

MO71 Change global Queue List attributes

Pressing   OK   or  Apply  on the global change list dialog will set the new default and all queue managers that have not had their list changed by the above mechanisms will pick up these new defaults. Pressing Apply All on this dialog will set all queue managers to use this list instead of anything that may have previously been altered by the above mechanisms. Because this is a ‘destructive’ setting (i.e. you lose previous set up you might have done), there is a confirmation dialog for this change. This change is also remembered across a restart of the MO71 program.

MO71 Change global Queue List attributes Confirmation

Changing columns in a filter

You can also change the column display from within a filter. This can particularly useful when creating pre-defined dialogs. Especially if you want to have several different ‘default’ sets of columns.

This can be done in two ways. Firstly by adding a ‘#’ character after a keyword or user variable name, to show it as a column on the end of the display. The example below has a filter which creates a user variable called “Fullness” and as a result of the ‘#’ character on the end, also displays that as a column.

MO71 Fullness column

The other way to manipulate columns from within a filter is to use the showcol and hidecol functions. This is very useful in a pre-defined dialog, allowing you to change the default set of columns to exactly what you need for this dialog. You might, for example, have several different queue lists, one for cluster queues, one for transmission queues, and one for dead-letter queues across all your queue managers. You can imagine wanting slightly different columns on display for each one.

The showcol function takes the MQSC spelling of the keyword and the column position, and the hidecol function just takes the keyword.

MO71 showcol hidecol

Heopfully now you can have exactly the columns you want on display in any list you are viewing. If you have any questions please leave a comment below, or get in touch.


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.

Looking forward to MQTCv2.0.1.7

MQTC IconIt’s nearly September, and in less than four weeks is the MQTC conference in Sandusky, Ohio.

MQTC – the only conference dedicated to IBM MQ – takes place from September 25 to September 27. There is a full schedule of technical sessions as well as a number of vendor sessions. There’s also lots of information about the conference on the CapitalWare Blog, and you can follow the twitter hashtag #MQTC2017.

MQGem Software is a Gold Sponsor of the conference, so come and find us in the evening Sponsor Pavilion, held in the Zambezi room, on Monday and Tuesday, and we can demonstrate any of the MQGem products to you and you can enter our prize draw. Or just grab a beer from the bar and come and say “Hello”.

Paul Clarke and Morag Hughson will be there from MQGem Software, doing a number of technical sessions:-

Title:
Speaker:
Scheduled:
Introduction to the MQI
Morag Hughson
Monday 1:00pm Leopardwood; Tuesday 2:30pm Aloeswood
Abstract: This entry level session will teach the basics of the beautifully simple MQ API – the MQI. You’ll have heard many describe how writing an application for MQ is very simple, just MQPUT a message, or MQGET a message. Come to this session and learn it for yourself. Example code in C and COBOL will be used, and a live demonstration using an API Exerciser will show how some of the input and output fields operate.
Title:
Speaker:
Scheduled:
Learn to code the MQ Message Property MQI calls
Morag Hughson
Monday 3:50pm Rosewood; Wednesday 9:50am Leopardwood
Abstract: This session will introduce you to the MQI message property calls. You’ll learn how to create message handles, and use them to populate, or read message properties on an IBM MQ message. Example code in C and COBOL will be used, and a live demonstration using an API Exerciser will show how some of the input and output fields operate.
Title:
Speaker:
Scheduled:
Using Application Activity Trace
Morag Hughson
Tuesday 9:50am Aloeswood; Wednesday 3:50pm Aloeswood
Abstract: Application Activity Trace is a feature of IBM MQ that allows you to discover exactly what the applications connected to your queue manager are doing. You can see the object names that they open and the options they use on the various verbs they call. You can find out about the size, persistence, priority and more, of your messages. Please note, this feature is only available on the Distributed platforms.
Title:
Speaker:
Scheduled:
Introduction to MQ Clients
Paul Clarke
Tuesday 8:30am Aloeswood; Wednesday 1:00pm Leopardwood
Abstract: This session introduces the IBM MQ clients: what they are, on which platforms they run, and how customers use them in their applications. We will mainly focus on the ‘C’ IBM MQ MQI client, but will also introduce the Java and XMS clients. The session will also discuss a number of basic implementation considerations, including when it may be appropriate to use each client and describe new client features. The intent is to familiarize you with the things necessary to succeed with a simple IBM MQ client implementation.

Paul will also be giving two vendor sessions:-

Title:
Speaker:
Scheduled:
The MQGems – MQ Administration tools from MQGem Software
Paul Clarke
Monday 11:15am Rosewood
Abstract: In this session, Paul Clarke, founder and CEO of MQGem Software, will take you through the administration tools that MQGem produces. This includes MO71 – our GUI administrator for MQ and MQSCX – a huge improvement on MQSC. The presentation will be largely based on demonstrations of the tools.
Title:
Speaker:
Scheduled:
The MQGems – Message manipulation tools from MQGem Software
Paul Clarke
Wednesday 11:15am Leopardwood
Abstract: In this session, Paul Clarke, founder and CEO of MQGem Software, will take you through the message manipulation tools that MQGem produces. This include MQEdit – our GUI Message editor for MQ, and QLOAD – the load/unload messages tool. The presentation will be largely based on demonstrations of the tools.

We look forward to seeing you there!

Application Activity Trace Viewer

IBM MQ has a feature called Application Activity Trace, which allows you to trace what an application is doing, see the progression of MQ API calls, the objects utilised, the options used, the time taken for each call and so on.

To get the most out of this feature, which writes its output as PCF messages, you need to be able to, not only read the content of those PCF messages, but display them in a way that allows you to drill down into the data, exclude data from your view to allow you to focus on what’s important, search for particular objects in use, or particular reason codes, and so on.

To this end, MO71 now has an Application Activity Trace viewer. At it’s simplest, it allows you to see the progression of MQ API calls, just like the IBM-supplied sample amqsact. However it can do so much more than that.

Activity Trace Output

MO71 Activity Trace Output

Drilling down

Rather than having to decide to view every MQ API call in high detail, the viewer allows you to drill down into the verb you are interested in, without the confusion of seeing high detail of everything else at the same time.

Activity Trace Drill down MQINQ

MO71 Activity Trace – Drill down into MQINQ

Activity Trace API Selection

MO71 Activity Trace API Selection

Filter the output

With a trace that spans many pages full, even when only showing one line per verb, you may wish to reduce the clutter on your screen further. You can filter the output in many different ways to see what you’re looking for. For example, you could choose to hide all the MQPUTs and MQGETs and focus on the other calls, like the MQOPENs.

Activity Trace No PUTs and GETs

MO71 Activity Trace with PUTs and GETs excluded

You can filter the output to focus on a particular object or objects that you are interested in, or a particular process id. In fact there are many different factors that you can used to filter down the data to make is easier to view.

Activity Trace Settings

MO71 Activity Trace Settings Tab with filtering

Health-checking your application

There are a number of behaviours that MO71 can check for in your application. These are listed on the Health tab, and if any issues are found you will see them highlighted with a red exclamation mark. You can display the instances in a separate window which then allows you to jump into the main output window at the point where the issue was detected.

Activity Trace Health

MO71 Activity Trace Health Tab

The current list of health issues is not final, and if you have any other issues you would like to see MO71 check for, please comment below or get in touch in the usual ways.

The Application Activity Trace viewer in MO71 will help you make sense of, and get great insight from, your tracing of your applications.


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.

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.