After many years on MQDev, we are moving to Messaging on Developerworks. It's been good while it lasted, but we're looking forward to the upgrade, and hope that you'll like it too! You'll be able to view not only blogs, but get easy links to demo videos, certification, support, samples, and more, all from one central hub. We're working towards customising parts of the site for specific users, so whether you're interested in MQ on distributed, MQ Appliance, MQ for z/OS, or what MQ is doing in the Cloud arena, you'll be able to find something for you. You'll still be able to access all of the MQDev blogs through the new site through a link at the end of the blog page, but no new content from MQDev will be posted. All new content will be on Developerworks instead.

You'll be able to find all of the MQ blogs here. When we start writing blogs on the new site, you'll be able to subscribe as before. For now, you'll see the blogs from this site in the feed, but as they get replaced by newer blogs, you'll have to use the link at the end of the page to get to the MQDev archive.

We plan to continue to evolve our Messaging on Developerworks site to make it as useful as we can to you. Please don't hesitate to let us know how we're doing.

Other changes:

There have been other changes to our social channels of late. In case you've missed it, this is where we've gone:

MQ on linux platform by design uses O_DIRECT feature when writing to the recovery logs. But some linux file systems do not support O_DIRECT flag. In such case O_DIRECT feature has to be disabled manually to start the queue manager or create the queue manager. So we have to check linux file system's support for O_DIRECT else crtmqm will fail with AMQ8101 error code or strmqm will fail with AMQ7047 error code. In either case, under MQ traces we can see the following
------{ mqloWriteFile
FileHandle(C) Length(12288)
Data: 0x00003000 0x00000016
Log write error 22, returned -1
-------{ xcsGetEnvironmentString
xcsGetEnvironmentString[MQ_RETRY_WRITE] = NULL
-------}! xcsGetEnvironmentString rc=xecE_E_ENV_VAR_NOT_FOUND
0x0000: 16688020 |.h. |
BytesWritten(0)
------}! mqloWriteFile rc=hrcE_MQLO_BPSE

The above "Log write error 22", error 22 translates to "EINVAL" which indicates the file system does not support the O_DIRECT feature.
There are 2 ways to disable this feature
1) Set the environment variable "AMQ_INHIBIT_O_DIRECT=1"

Summary: This blog is for the workaround when user tries to launch the MQ Explorer on the back level MQ Fix pack, i.e. when user installed latest MQ Fixpack ex: MQ 7508 Fixpack and uninstalled 7508 FP and when tries to launch MQ explorer on back level Fix pack 7507, might end up with error while launching the explorer using command

Error you could see as below while launching MQ explorer

And in the *.log - <MQ Installation Directory>\WebSphere MQ\MQExplorer\eclipse\configuration\*.log

Close the budle.info file after adding the above command and try to launch the MQ explorer, It should launch without any error.

Note: weaving,7.5.0.201608130145 - this version, Date and Timestamp varies for the version of MQ installed on your computer. If version, date and timestamp does not match, the explorer with not launch, it will throw the error.

We have had a couple of questions about which file system people should use for their distributed production queue manager.

One person said they found an old server which had never been used. They put a current Linux on it, and ran a queue manager which became the production queue manager.

Full marks for reuse - but it did not give the throughput they needed, so no marks for planning.

We also had a question asking if we could come up with a tool or document which could predict the throughput for a given file system and persistent message profile.

These questions are both connected. Starting from an existing file system and putting a queue manager on it is approaching the problem the wrong way.

You should approach the planning from an architectural and a business perspective. The Agile approach of "Fail Fast Fail Often" is not a good strategy for this.

From an architectural perspective

Does this queue manager need to run on more than one box, eg are you using a standby queue manager?

If so then you have to use external disks - not locally attached to the server.

If your queue manager only every runs on one box, you can use local or remote disk as long as they meet the requirements

If your disks are on a network - then the network will add time to each IO. You may need to tune the IO, especially if large buffers are being written ( over 200KB)

Do your disks have contention from other users?

Does any other work affect the disks?

From a business perspective

Does the solution meet your availability needs? For example you may need mirrored disks which tend to be slower,

Is there may be a requirement that the time in MQ has to meet Service Level Agreements - such as less than 10 ms in MQ. If the response time of your disks are 5ms then you are unlikely to meet the SLA. Do you need Solid State drives (SSD) or will Hard Disk Drives(HDD) do?

Often you have little choice for where you place your MQ files as you have to follow your operational standards. You need to understand the impact of where you put your files.

To find if your environment can achieve the required throughput and meet the response time criteria, you need to run a workload similar to your peak workload to see.

One word of warning - do this during peak activity - not late at night when the system is not being used - as you want the disk load, and the network load you will get when running it in production.

z/OS Perspective

I discussed this with Tony Sharkey MQ on z/OS Performance and he summarised it as

MQ Internet Pass-Thru (MQIPT) is an IBM MQ product extension that helps you connect MQ queue managers or clients that are not on the same network securely. It’s free to download from the IBM MQ SupportPac website, and is fully supported when used with a supported version of IBM MQ.

As MQIPT fix pack 2.1.0.3 has just been released, I thought I’d take this opportunity to briefly highlight what this SupportPac offers.

What can MQIPT do?

MQIPT listens on one or more TCP ports and forwards MQ connections that it receives. These connections can be between two MQ queue managers, or an MQ client and a queue manager. The presence of MQIPT is completely transparent to the clients and queue managers.

It runs as a standalone service and doesn’t need to run on the same system as a queue manager or client. In a basic configuration MQIPT just forwards connections to a queue manager, as shown in this diagram.

As MQIPT understands the MQ network protocol it can perform various transformations on the connection, such as TLS encryption or decryption, and wrapping the connection in HTTP to enable MQ connections to be tunnelled through the firewall using existing HTTP proxies.

For more flexibility, you can use a pair (or more if you need to!) of MQIPT instances. In this example a pair of MQIPT instances is used to secure a connection with TLS between the two instances. The queue managers are unaware that MQIPT or TLS is in use.

Note that you don’t have to use a pair of MQIPT instances to use TLS. MQIPT can also communicate directly with MQ using TLS.

Why would I use MQIPT?

There are two main benefits to using MQIPT - improved security, and easier network administration. Let’s look at an example of how you could use MQIPT.

A common use of MQIPT is to place it in the DMZ, so that it acts as a single point of access to your MQ network from the internet. External queue managers or clients connect to MQIPT rather than directly to the queue manager, as shown in this diagram.

This has the benefit of pushing security checks out to the edge of your network, as MQIPT can apply rules to connections, such as checking the client TLS certificate, before the channel can connect to the queue manager.

If the MQ channels are using TLS, then MQIPT will also provide a break in the TLS session in the DMZ, which is something that many organizations require.

The other benefit of this configuration is that it reduces the number of firewall rules needed to allow connections to the queue manager, as all external connections to the queue manager will now come from the machine where MQIPT is running.

Today IBM announced the availability of IBM MQ for HPE NonStop V8.0, the first release of MQ on the NonStop platform since Version 5.3. This new version supports 32-bit and 64-bit native applications on both NonStop X and NonStop i platforms, extending Version 5.3's support for 32-bit applications on NonStop i.

IBM MQ for HPE NonStop V8.0 is a new port of the product based on IBM MQ V8.0, including many new features that have been introduced into the MQ product since V5.3 was released, and also taking advantage of the specific features of the NonStop architecture. New features also found in other MQ products include more queue manager controls, MQ client connections, better messaging support, and support for JMS 2.0, while some of the NonStop specific features are non-native TNS language support, integration with TMF for transactional support, and richer EMS event handling.

This new version of the product is being delivered and maintained using IBM’s continuous delivery model initially, where new product features and fixes will be delivered in 8.0.x releases. IBM intends to offer a traditional long term support model once full functional parity is achieved with the V5.3 version.

IBM MQ for HPE NonStop V8.0 will be available this Friday 23 June via Passport Advantage. For more information, see the full Product Announcement.

I was trying to specify message selection strings in MQOPEN and I was getting no messages when I did my MQGET. I thought I would pass on the micro gems of what I learned.
I was running on z.Lunix and my C program had parameters -SSKEYWORD=kw and -SSVALUE=value. My program then built the SelectionString from kw '=' value.
When I specified myprog -SSKEYWORD=COLOUR -SSVALUE='BLUE' no messages were retrieved. I was expecting the SelectionString to be COLOUR='BLUE'

I found I had to specify mqgmo.Version = MQGMO_VERSION_4 instead of using the MQGMO_DEFAULT

Using /opt/mqm/samp/bin/amqsbcgc CP0000 colin 3 gave me return code 2058 - because I was trying to use the client program without setting up the connection information. It worked when I used amqsbcgand local bindings.

I used /opt/mqm/samp/bin/amqsbcg CP0000 colin 3 to display the message data in the RFH2 header - the message was correct

It turned out I had to escape the quotes as the bash shell was treating 'BLUE' as BLUE and so my selection string was COLOUR = BLUE (without the quotes), which means check to see if property named COLOUR has the same value as the property named BLUE. Messages property BLUE did not exist, the comparison was not true - and so the get failed. When I specified myprog -SSKEYWORD=COLOUR -SSVALUE=\'BLUE'\' using the bacxkslash \ it worked.

I had printed out the SelectionString being passed to MQ - and this was "COLOUR = BLUE" and I could see this was 'obviously' correct. If I had looked more closely I would have spotted the missing quotes and saved myself a couple of hours debugging.

When I specified message property COLOUR=BLUE, and then added a second colour COLUR=RED to the message, there was only one message property COLOUR=RED. as the second instance replaced the first one.

Installing MQ without a Java Runtime Environment or removing one already present

In IBM MQ releases prior to 9.0.2 the product always installed a Java Runtime Environment (JRE). This was tied into MQ in such a way that once installed, it could not be properly or safely removed without removing the whole of MQ. For some customers this had become a problem.

I should say at this point, for those reading who are happily using Java with MQ, that our Service team does update the installed JREs in every fix pack to keep your Java environment secure. In addition, for those security issues that are too urgent or do not come to light at a convenient time for inclusion in the next fix pack, our Service team will provide an ifix which replaces the entire JRE with the latest, fixed JRE level.

However, for some customers who were not actively using Java in their MQ environment, this seemed to be a risk they were not willing to take. Some even had company policies in place that discouraged or forbade them from installing more JREs. As a result of this, we received requests for enhancement from several customers and in MQ 9.0.2 we updated the installers to allow you to omit the JRE from an installation.

Linux Installer Changes

For the Linux installers, the main change here was to loosen the package prereqs so that GSKit RPM could be installed without installing the JRE RPM. (The Server RPM prereq on the JRE RPM had been removed a while back.)
All other prereqs were already in place to ensure that if you install an MQ component that is written in Java you will be required to install the JRE component as well.

Windows Installer Changes

If you do a typical install of IBM MQ 9.0.2 or later you will end up with an installation that *DOES* contain a JRE.

If you upgrade to MQ 9.0.2 or later from an existing pre-9.0.2 installation, the upgrade will add the Java Runtime Environment installable feature (as all installs prior to 9.0.2 had a JRE and an upgrade updates all the install features present, it would have made little sense to remove the JRE during an upgrade.) However, you can then modify the installation and remove the JRE, if you so wish.

If you do not wish to install the JRE at install time, you should choose the "Custom Install" option which can be found on the panel immediately following the license acceptance panel. You can choose installation name, installation description, and installation folder here or accept the pre-filled values which will give you the same selections as a "Typical Install".

You will then be presented with the feature selection panel which has a new item on it - "Java Runtime Environment":

As in a typical install, the Java Runtime Environment installable feature is selected. If you do not wish to install it, you can now deselect it. You can add or remove other features as you choose and when you click "Next >" the installer will check whether the features you have chosen are consistent. If they are not, you will get a panel something like this:

Pic 2. Panel warning of inconsistent feature selection

This is because it is not only user programs that may be written in Java. Portions of the MQ product itself are written in Java and can be run only by the JRE that MQ installs. As documented in the URL in footnote (1), these include:

MQ Explorer

Telemetry Service

Managed File Transfer (Service, Agent, Logger and Tools)

AMQP Service

Web Administration

In the above example, amongst other features, the user had chosen to install MQ Explorer. However MQ Explorer is a Java application and without the MQ JRE, it cannot function.

These warning panels will stop you installing any MQ feature that you will be unable to run and must be resolved before the installation can continue. The features named cannot use another JRE but rely on the MQ JRE for the customisations it contains (like the enhanced IBM security providers) so the only way to satisfy them is to install the JRE. As the panel says, you must now decide which is more important to you: removing the JRE or installing the selected Java-based MQ features.

If you want to know what a given installable feature contains see footnote (4).

Removing an already-present JRE on Windows

Firstly, ensure that your installation is at MQ 9.0.2 or above. Although there was a JRE in MQ 9.0.1 and before, the installer had no knowledge of the JRE as an installable feature in its own right and therefore had no ability to uninstall it.

Launch the installer executable appropriate to the release of installation you wish to modify, select "Maintain or upgrade an existing instance" and select the installation to modify.

In the "Program Maintenance" panel select Modify.

Deselect the "Java Runtime Environment" feature and click "Next >".

If any features require the JRE you will be shown the "Requires 'Java Runtime Environment' (JRE)" panel as before. Proceed as described above.

Removing an already-present JRE on Linux

Firstly, ensure that your installation is at MQ 9.0.2 or above, then issue the command:

rpm -e MQSeriesJRE

If you get failed dependencies error(s) the listed RPMs will be the ones that require the persence of the JRE. Just like the Windows inconsistent features panel above, you now have to decide what is most important to you: removing the JRE or enjoying the functionality contained in the listed RPMs (3).

Running MQ without a JRE Installed (Windows and Linux)

Given that you cannot install the components or features that absolutely require a JRE without installing the JRE, there should be little disruption to the way you work. However, there are a couple of exceptions. In two areas the hard prereq checking is not performed as there is an alternative to installing the MQ JRE:

IBM MQ Classes for Java / IBM MQ Classes for JMS

These classes will run perfectly well with JREs other than the IBM JRE provided by MQ. The only (obvious) caveat being that if your application specifically uses IBM JRE extensions you will need an IBM JRE rather than an Oracle one.

Certificate management

The GUI usually used for managing certificates, "strmqikm" (ikeyman) is written in Java. If you did not install the MQ JRE you will have to use the text-based version of the program. "runmqakm". This is described in the Knowledge Center (2).

Conclusion

Hopefully you will find it simple to remove a JRE following the above instructions (and adding one back in is just as easy). If you have local policies about not installing JREs, it is probably a good idea to look up the features you want to use in the links given in the footnotes before you come to install the product and find MQ requires a JRE to do what you want it to do.

I am aware I have not covered Windows silent install here and this post is quite long already. That will have to be a topic for another day.

FOOTNOTES

(1) For a full list of all the installable features that require you to install the MQ JRE, see table one on this page in the knowledge center:

So here is Colin's hierarchy of needs... so fix 1) then fix 2) etc
1. CPU - is the image short of CPU?
2. Memory (real and virtual storage) - is there any paging
3. IO - check the IO response time is good
4. Check network response time is good
5. Check subsystem - eg MQ, DB2 are giving good response time
6. Check applications

If you have fixed a problem - start your checks from the top. For example fixing the IO problem allows much more work to flow - so there may now be a CPU problem.

If you have a performance problem, go through the list to see where the problem is. It may save you time before calling for help, as the support team may assume you have gone through the list.

I showed this list to a colleague who said it is really obvious - but if it is so obvious - why do we have so many problems caused by it!

As I was writing this, I was asked about another 'MQ problem' which turned out to be CPU.

Here are some real examples of problems I have dealt with. Tick the one which you have experienced

"The MQ performance was so bad - I could not even logon to the machine to display the MQ error log" - this was a lack of CPU in the VM

"It cannot be a CPU problem there are 20 cores on this machine" - yes but the VM is only configured to have one core. Defective End User

This server does not have a CPU problem" - yes - but half the messages are being routed (using MQ clustering) to that server which does have a CPU problem - problem between keyboard and chair.

"On average the CPU is only 50% busy" - yes - that is because you have peak workload where you run out of CPU followed by long periods where nothing happens.

Whoops I made the MQ buffer pool so big - it caused paging.

Throughput dropped at 8pm each evening - they did backups at 8pm - and the IO response time doubled - so commits took twice as long and transaction rate halved.

MQ distributed performance was poor - someone had reconfigured the connection to the SAN - IO problem

"You are running MQ on that system?- that SAN is due to be replace next month as it is old and overloaded. The reason why that machine was not being used is that it is so old and about to be scrapped - and you are running production MQ on it? " - lack of planning and communications

MQ throughput between MQ on z/OS and Linux died every Saturday. - Backups taken from all distributed machine to z/OS - which swamped the network

MQGETs are slow since we made the messages persistent - messages were out of syncpoiint - so IO for every message.

MQ throughput very low - because the application is doing a remote database insert over the network. The MQGET was very quick - the database update was not..