What is an 801 Queue Manager?

So you’ve been told you need an 801 queue manager for some new function. But what does that mean exactly?

What is MQ 801?

What is MQ 801?

IBM MQ has two sets of numbers that are important when identifying what queue manager you have. You have the 4-digit version number V.R.M.F – that’s Version, Release, Modification and FixPack. This is the number you will see output by the dspmqver command. Its purpose to identify what level of code you are running, and service will always be interested to know your full V.R.M.F. if you raise a PMR for example.

Name: WebSphere MQ


Level: p750-002-131001_DE

BuildType: IKAP – (Production)

Platform: WebSphere MQ for Windows

Mode: 32-bit

The other number you will encounter is the command level. This is the number you will see output by the DISPLAY QMGR command in the CMDLEVEL field (the VERSION is also part of this command’s output in newer versions of MQ). The purpose of CMDLEVEL is to convey what commands, object types and attributes the command server understands, and is thus used by administration tools to ensure that they send appropriate commands to the command server. It has been available since the very first version of MQ, so you can ask any queue manager for its CMDLEVEL and it will be able to respond. It is also an MQINQ-able field as another way to discover it.


AMQ8408: Display Queue Manager details.



It is generally the case that the V.R.M part of the 4-digit number matches the Command Level (as in the above V7.5.0 examples), but not always. If new attributes, object types or commands are introduced in a FixPack, then the command level must be increased (to allow administrative tools to discover that the command server will accept these new attributes) but the V.R.M.F only changes in the 4th digit. This happened in FixPack V7.1.0.2 where Command Level 711 was introduced to cover the new attribute CERTVPOL, and it has happened again in FixPack V8.0.0.2 where Command Level 801 has been introduced to cover a number of new attributes.

Since this is new function being shipped through the Service stream, it is not enabled by default. FixPacks can be removed and so the queue manager must be able to revert to running without the code from a FixPack. It cannot revert once a change has been made to the Command Level. So the user wishing to make use of the new features protected by the Command Level has to do a positive action to enable the new Command Level which at the same times confirms that this queue manager will not be able to revert back to previous level.

So what is this action that must be done to choose to use the new Command Level? It’s an extra parameter on the strmqm command. Note that when you issue this command it only alters the Command Level, it doesn’t actually start the queue manager. So once complete, you must then issue a normal strmqm command.

strmqm -e CMDLEVEL=801 QM2

When you issue this command to upgrade the Command Level with the above command, you’ll see a message confirming this at the end of the start-up messages.

WebSphere MQ queue manager ‘QM2’ starting.

The queue manager is associated with installation ‘800FP2’.

5 log records accessed on queue manager ‘QM2’ during the log replay phase.

Log replay for queue manager ‘QM2’ complete.

Transaction manager state recovered for queue manager ‘QM2’.

Migrating objects for queue manager ‘QM2’.

Default objects statistics : 3 created. 0 replaced. 0 failed.

New functions up to command level 801 enabled.

As you can see from the above messages, this also migrates the queue manager. This is always the case the first time a queue manager starts up with a new command level, and is true whether the change to the command level was caused as the result of a version-to-version upgrade, or this method of selecting a command level delivered in a Fix Pack. Remember that migration is never reversible. You can read more in Maintenance, upgrade, and migration.

This post equally applies if you need an 802 queue manager, just change the number accordingly. The 802 Command Level was released with V8.0.0 Fix Pack 3.

Now you have an 801 queue manager! To find out what you can do with it, read What’s in Command Level 801

IBM Certified Specialist

Morag Hughson is a Certified IBM MQ Specialist
IBM Certified System Administrator – MQ V8.0
Find her on: LinkedIn: http://uk.linkedin.com/in/moraghughson   Twitter: https://twitter.com/MoragHughson   SlideShare: http://www.slideshare.net/moraghughson


2 thoughts on “What is an 801 Queue Manager?

  1. Hello Morag,

    Excellent blog about the MQ Command Level. The Knowledge Centre did not do as good a job of explaining it as you have. However, one thing you did not tocuh on was how the Queue Manager command level relates to when or whether queue manager migration takes place upon first starting the queue manager when the code level has been upgraded.

    So, for the example you gave above for FixPack V8.0.0.2 for which the command level is 801 and not as might be suggested from the VRM (800), upon first starting a queue under this code level, would the queue manager be migrated?

    Shedding more light on when migration happens and whether a migration is reversible would be much appreciated.

    Many thanks.


    • Hi Vic,

      Happy to hear that my blog post was useful. I didn’t cover migration, because the topic at hand was the concept of the new command level. The IBM Knowledge Center does have a page that covers migration in all its various guises, Maintenance, upgrade, and migration, which has perhaps the most important sentence thus:-

      Migration always follows an upgrade that changes the queue manager command level, both automatic and manual changes.

      So to answer your direct question, yes, when you set the command level to 801 and start the queue manager, the queue manager is migrated. Just as it is always migrated the first time you start a queue manager and it has a new command level, be that through this strmqm method, or through a version-to-version upgrade.

      Migration is never reversible. This is probably quite obvious when you go to a new version, i.e. moving from V710 to V800. It’s perhaps less obvious when the new command level comes about during maintenance cycles. This is why the new command level delivered in a Fix Pack is not forced on you by IBM MQ, and instead you have to make a conscious action to choose the new command level. Fix Packs can be rolled back, and that needs to be able to continue to be done even when a Fix Pack introduces a new command level. It is only when you take the action to move up to the new command level with the special variant of the strmqm command that you are indicating that you are happy not to be able to roll back the fix packs below that level.

      P.S. I added some of this comment into the text of the post too.

      Hope this helps


The team at MQGem would love to hear what you think. Leave your comments here.

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.