This format is a little tricky to extract the data from to reinstate your message. As you can see above, you get the MQMD and the message data all in one block. It gets even more tricky when your message is broken up into several log records!

This version of QLOAD hopes to make the process of recreating message from your transactional log files much simpler to do. It can only work when the messages you want are in the log file though. There’s no magic!

Running QLOAD against the queue manager log

With the following invocation, QLOAD will run the dmpmqlog utility and parse through the output looking for the queue you requested, in this example HELLO.WORLD.Q, and write any messages it finds to the HELLO.WORLD.RCOV queue on queue manager MQG2.

qload -m MQG1 -j* -i HELLO.WORLD.Q -m MQG2 -o HELLO.WORLD.RCOV

Since you are reading the log files using dmpmqlog, the queue manager, MQG1, cannot be running when this command is issued and so the messages cannot be put onto a queue on that queue manager as part of the command. In this example I’ve chosen to put them onto a side queue on another queue manager but equally I could write them into a QLOAD file and then later put them onto the queue manager once it has started up again, as follows:-

qload -m MQG1 -j* -i HELLO.WORLD.Q -f HELLO_WORLD.qld

strmqm MQG1
qload -m MQG1 -f HELLO_WORLD.qld -o HELLO.WORLD.RCOV

Running QLOAD against output from dmpmqlog

If you have already run dmpmqlog, perhaps to determine whether the messages you wish to retrieve can be found in the log, then you may have already spent a few minutes waiting for the utility to complete. You can use the output files you generated from the utility as input into QLOAD.

dmpmqlog -m MQG1 -b > dmpmqlog.txt

qload -j dmpmqlog.txt -i HELLO.WORLD.Q -m MQG1 -o HELLO.WORLD.RCOV

Running QLOAD against copied off queue manager logs

A third alternative is to run QLOAD against queue manager log files that have been copied off. In this case you provide QLOAD with a directory containing these files.

This command drives dmpmqlog with the -f parameter, and so the criteria for this directory must follow what is described in Knowledge Center for running dmpmqlog in that way. In addition, you must use the -m parameter to specific the queue manager name that these log files came from so that queue names can be found, and that queue manager cannot be running at the time.

The specified directory must contain the log header file (amqhlctl.lfh) and a subdirectory called active. The active subdirectory must contain the log files. By default, log files are assumed to be in the directories specified in the IBM MQ configuration information. If you use this option, queue names associated with queue identifiers are shown in the dump only if you use the -m option to name a queue manager name that has the object catalog file in its directory path.

QLOAD filtering

Whichever of the above methods you choose to use, you can add many of the QLOAD filtering options to your command.

For example, you can find all the messages containing a particular search string.

QLOAD also has time based filtering, so if you’re looking for a message from hours, days or weeks ago, you can go directly to that time period. This example is looking for messages that were put onto the queue between 18 and 19 hours ago.

Note: Filtering by Selection String (the -H parameter) is not available when your input source is a file (either a QLOAD file or an MQ log file) since it uses the Selector feature of MQOPEN.

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.

This blog post is here to assure you that the tools you know and love from MQGem Software; MO71, MQSCX, MQEdit and QLOAD can all also be used with IBM MQ running on IBM Cloud.

Once you have created your MQ on IBM Cloud Service and Queue Manager, as shown in the above video, and your queue manager is up and running, you’ll have a view something like this.

A list showing my Running queue manager

Click on the three vertical dots on the right of your queue manager to “Download Connection info”, or alternatively view the details of your queue manager and then there is a button there too which allows you to download the “Connection Information”. Either way, you’ll be presented with a pop-up which allows you to download a plain text file which contains the queue manager name, hostname, port number and a couple of channel names, one called an Application Channel and one called an Administration Channel.

IBM Cloud Download Connection info

In order to remotely connect to your IBM Cloud queue manager you will also need to be able to log in. As the MQ on IBM Cloud documentation describes here, you need the API key as your password to go with the user id ‘admin’. Follow the instructions on that page to obtain your API key.

Now you have all the pieces of information you need to set up any of the MQGem Software tools to administer your queue manager on IBM Cloud. As a reminder, these are the things you will need.

Item

From where

Queue Manager Name

You invented it when you created the queue manager. If you’ve forgotten it, it’s also in the text file you downloaded with the connection information.

Channel Name

The “Administration channel name” can be found in the text file you downloaded with the connection information.

Connection Name

This is built by concatenating the “Hostname” and “Listener port” details (with brackets round the port number) that can be found in the text file you downloaded with the connection information.

User ID

This is ‘admin’

Password

This is the API Key that you created by following the linked instructions.

On the pages that follow, we cover how to use the above information you have gathered in your table to configure each of our tools to connect to your IBM MQ in IBM Cloud Queue Manager. Go directly to the page for the tool you want to use, or page through each one in turn.

MO71

MQEdit

MQSCX

QLOAD

If you don’t have a licence and would like to try out any of our tools then send an email, noting which tool you’d like to try, to support@mqgem.com and a 1-month trial licence will be sent to you.

MQGem Software is pleased to announce that a new version of MQSCX, our command line extended MQSC tool for IBM MQ, is now available.

This is a mini-release, specifically to release the first of the below features. But then we added a couple more things at the same time!

Issue RESET QSTATS as an MQSC command

Sparked by a conversation on MQSeries.net we were intrigued when one user asked us whether it would be possible to provide RESET QSTATS as an MQSC command on the distributed platforms using MQSCX. Turns out it is possible!

Support certlabl on connect

The =conn command provides for a number of client channel configuration attributes, and now certlabl is among them.

Press Any Key?

Provide a simple way of getting user key input

This version introduces the getkey() function which will return the next key pressed by the user. This can be useful to, for example, navigate your way through a script menu, or to exit from a while loop in a script at the user’s command.

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

MQGem Software is pleased to announce that a new version of QLOAD, our queue load/unload tool for IBM MQ, is now available.

This release was created for one specific customer requested feature which we call Required Rate Processing.

Required Rate

This feature allows you to test the speed that your system, or specific applications in your system, can process messages. You may have a target rate you need to be able to achieve, and you can use QLOAD to send messages through the system at that rate to see whether the system (the channels and the applications) can keep up. You may for example have TLS channels; or message compression; or AMS message level encryption applied to the messages which are of course, changing the performance profile of the system. With QLOAD you can test the rate using exactly the same shape and size of messages that you will use in the production environment.

Starting with a queue that contains a representative selection of example messages, you can then use QLOAD to copy those messages and inject them into the system at the rate you require. In the example that follows, the required rate is 500 messages/second and the test is to run for 10 minutes.

qload -m MQG1 -i EXAMPLE.MSGS -o TARGET.QUEUE -R500:600

QLOAD will browse the EXAMPLE.MSGS queue and send copies of those messages to the TARGET.QUEUE. When it reaches the end of the EXAMPLE.MSGS then it will go back to the beginning of the queue and send them again, as often as required until the test ends. You can just have a single message on the queue and send it repeatedly, but to offset the cost of resetting the browse, it’s better to have 10 or more messages on the queue. In reality all your messages will not be the same, so a good selection of example messages is certainly worth collecting.

If you want the test to run until you tell it to stop, you can indicate that you want it to run indefinitely with an asterisk for the duration.

qload -m MQG1 -i EXAMPLE.MSGS -o TARGET.QUEUE -R500:*

There are two other ways you might use this feature.

Discover Achievable Rate

Instead of telling QLOAD to run at a certain rate, you might instead want to discover what your highest rate could be.

To run QLOAD in this way, you use a command like this:-

qload -m MQG1 -i EXAMPLE.MSGS -o TARGET.QUEUE -R*:*

And you will see output like the following, as QLOAD ramps up the rate.

It does this by monitoring the depth of the target queue, which might be a transmission queue being read by a channel, or it might be an application queue being read either by the read application or by another instance of QLOAD acting as a sink.

qload -I TARGET.QUEUE -f null -w600

Trickle Feed the contents of a queue

So far you’ve seen QLOAD copy example messages from a source queue and inject them into the system over and over until the duration of the test is complete. Alternatively though, you could use this feature to move messages from a side queue (the contents of a batch run, or messages from a backout queue or a Dead-letter queue) back into the main system. If you have a large depth of these messages you may not want to load them back into the application queue all at once, since you know deep queues hurt performance. So instead you can trickle feed them into the system using QLOAD.

qload -m MQG1 -I SIDE.QUEUE -o TARGET.QUEUE -R50

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.

MQGem products licences are time based, allowing you to use the latest version of the product without needing to buy a new licence. One of the advantages of this is described as follows in the manual:-

Features are available sooner
Using this model it is not necessary for us to collect a large group of features together to ‘justify’ a new release of the product. Instead a new release can be made available whenever a new feature is added which is regarded as sufficiently useful since all current users will be able to migrate to the new version at no cost to themselves.

This allows us to do even very small minor updates to the products from time to time. These minor updates are notified to you in a couple of ways. At the end of each month, any minor updates will be included in the News section of our MQGem Monthly newsletter.

In addition to this, minor updates will be tweeted using each product’s hashtag on the day of the upload.

You can see all the minor updates so far using each of the following links. Even if you’re not a twitter user, these posts are all public for you to view. Below each link is an example tweet. Whenever possible, these tweets will include a screenshot to demonstrate the new update.

Remember, if you have a minor change you’d like to see to one of our products, please tell us about it. Small updates don’t have to wait for a whole new version!

If you don’t have a licence and would like to try out any of our products then send an email to support@mqgem.com stating which product you’d like to try and a 1-month trial licence will be sent to you.

You may have read an earlier post where we described being able to determine what version of CCDT you had in your hand.

How often have you had a CCDT file in your hand and wondered what version it was and whether you can give it to some of your known back-level client machines to use.

MQSCX can help you determine this. Open up your CCDT using the mqscx -n mode and then you can quite simply display the version number of all your client channels therein.

What you may not have realised from that post however, was that not only can MQSCX help to investigate what version number your CCDT is made for, it can also make a CCDT for the correct version as well. If you have back-level clients, it can be a real pain having to keep a queue manager of the same level around just to be able to create a CCDT that it will understand. Well, you can ditch that queue manager and use MQSCX instead. It’s really easy to do as well.

To use MQSCX to work with a CCDT, you need to use the -n parameter. This will then look for the CCDT file in the location specified by the MQCHLLIB and MQCHLTAB environment variables unless you provide the -t parameter to give it a specific file name. If one doesn’t exist, it will make a new one for you, and if one does exist it will read it and allow you to update it. In order to control the version of CCDT you are creating, you should additionally use the -V parameter which allows you to specify the version the CCDT file should be written as.

Here’s an example, run the MQSCX program like this:

mqscx -n -t C:\MQGem\CCDT\MQGEM.TAB -V7.0

And then you can use it to make DISPLAY, ALTER and DELETE commands.

MQSCX Extended MQSC Program – Version 8.0.0

CCDT commands directed to file ‘C:\MQGem\CCDT\MQGEM.TAB’

Licenced to Paul Clarke

Licence Location: Head Office

[12:02:10] DISPLAY CHANNEL(*) CONNAME VERSION

_________________________________________________

CHANNEL(MQG1.SVRCONN) CHLTYPE(CLNTCONN)

CONNAME(win12.mqgem.com(1602)) VERSION(8.0)

_________________________________________________

CHANNEL(MQG2.SVRCONN) CHLTYPE(CLNTCONN)

CONNAME(aix5.mqgem.com(4231)) VERSION(8.0)

_________________________________________________

CHANNEL(MQG3.SVRCONN) CHLTYPE(CLNTCONN)

CONNAME(mvs1.mqgem.com(1255)) VERSION(8.0)

_________________________________________________

Total display responses – Received:3

>

As you can see, at the moment all the channels in this CCDT are at V8.0 which means my V7.0 client won’t be able to read them. I need to make a change to each record to ensure MQSCX will write it out at version V7.0 as I have indicated on my start command. Helpfully, I can do that in one single command:-

ALTER CHANNEL(*)

This makes no actual change to the attributes of the channel definition, but does ‘touch’ each record to ensure that it gets the new version. Displaying the records again as above will show that the version number for each channel mentioned by the ALTER command (in this example all of them), now indicates it is at version V7.0, just what my back-level client application needs.

Exiting MQSCX and re-running it will show you that this earlier version of the CCDT has indeed been hardened.

Note that if you had been using some attributes introduced in later versions than V7.0, this information would be lost when altering the channel definition to be an earlier version.

If you’d like to try out MQSCX, please email support@mqgem.com to request a trial licence.

MQGem recently delivered a new version of MQSCX that supports the new IBM MQ V9 release. As well as support for the new command level, there were a number of other features in this new version of MQSCX. One of those new features was a bootstrap file. This is a well known named MQSCX script file that is always imported when you start up MQSCX. It can be a handy place to put any frequently used functions.

The bootstrap file can either have your frequently used functions included in it directly, or the bootstrap file can have =import file statements in it (or both). For example:-

Of course the bootstrap file could also be used to run a command, or a number of commands every time the program is started up. Anything you can do in a normal MQSCX script file (or interactively) you can put into the bootstrap file. Here’s one example, but of course I’m sure you can think of plenty of others.

I’m sure there are lots of other things you could do with the bootstrap file. Let us know in the comments if you have any other ideas.

If you are a current MQSCX licence holder, you can simply download the new version of MQSCX and start using it. If you’re not a current licence holder, and you’d like to try out MQSCX, please email support@mqgem.com to request a trial licence.