This is part of a series of small blog posts which will cover some of the smaller, perhaps less likely to be noticed, features of IBM MQ. Read other posts in this series.

As MQ queue manager administrators, we're well used to using the DISPLAY QSTATUS and DISPLAY CHSTATUS commands to get status about our queue and channel resources, but had you noticed there is also a DISPLAY QMSTATUS command? This command is only available on the distributed platforms, but I'll explain where to find the same information on z/OS as we go through the information that this command gives you.

Channel Initiator

The CHINIT field shows you the status of the channel initiator. This process is necessary in order for channels to be able to be trigger started or to retry, should there be a network break for example. In modern versions of MQ the channel initiator process is automatically started (by default - see SCHINIT parameter on ALTER QMGR) so it should always be running for you, but this field allows you to check.

On z/OS you can tell whether the channel initiator is running by checking the status of the ssidCHIN job. This address space is even more necessary on z/OS as without it channels cannot run at all.

Command Server

The CMDSERV field allows you to see whether the command server is running or not. Some installations choose to disable the command server in production thus disallowing any remote administration of the queue manager. This parameter allows you to check that the command server is in the expected state for your shop.

On z/OS you can tell whether the command server is running by using the DISPLAY CMDSERV command.

Clearly if it is not running a remote administrator cannot get a response to either command, so this is more useful as a local command.

Count of Connections

The CONNS field gives you a total of the number of applications connected to the queue manager. This will be equivalent to the total number of responses returned to you when issuing a DISPLAY CONN command.

There is no equivalent way to get this information on z/OS, although as noted above the same information is available by totalling the responses returned from DISPLAY CONN. Many IBM MQ administration tools give you the totals as a matter of course.

Logging

The CURRLOG, MEDIALOG and RECLOG fields are relevant if you are using linear logging. CURRLOG tells you what the current log extent is; MEDIALOG tells you what the oldest log needed for media recovery is; and RECLOG tells you what the oldest log needed for restart recovery is.

You can see the equivalent information in the z/OS MSTR job log in messages such as:-

CSQJ001I %CSQ8 CURRENT COPY 1 ACTIVE LOG DATA SET IS
DSNAME=CSQ800.CSQ8.LOGCOPY1.DS01, STARTRBA=0000000000000000
ENDRBA=0000000000437FFF

Installation Details

The INSTNAME, INSTDESC and INSTPATH fields describe the installation this queue manager is using and were added as part of the multi-version install feature in WebSphere MQ V7.1. These fields show a subset of the information you can obtain using the dspmqinst control command - a command that isn't available to a remote administrator, so these fields provide some of that information to those making remote inquiries.

On z/OS there isn't an installation name or description, but you can see the equivalent to the installation path by looking at the STEBLIB of your ssidMSTR job.

LDAP Connection Status

The LDAPCONN field was added in IBM MQ V8 and shows the status of the connection that the queue manager makes to an LDAP server. You can use an LDAP server as your user ID repository for user ID and password checking (by defining an AUTHTYPE(IDPWLDAP) authentication information object) - see "MQ v8 Setting up a QMGR to use LDAP Authentication" for more details about this new feature in IBM MQ.

Use of LDAP is not available in IBM MQ for z/OS V8 so there is no equivalent state on z/OS.

Multi-instance Queue Manager

When running a multi-instance queue manager you have a primary instance and, hopefully, a standby instance. In order to start your queue manager so a standby instance is permitted, you use a special flag on the start command:-

strmqm -m QM1 -x

As a remote administrator you can see that a queue manager permits standby instances with the STANDBY(NOPERMIT|PERMIT) field on this command.

The multi-instance queue manager feature does not apply on z/OS, though you could argue that the use of the z/OS Automatic Restart Manager (ARM) might be equivalent and so you could check the ARM settings on your z/OS queue manager to be sure it's going to be restarted if there is a failure.

Queue Manager Status

The STATUS field of this command will show whether the queue manager is STARTING, RUNNING, or QUIESCING.

You can see the equivalent status of a z/OS queue manager by looking for the the following console messages:-

CSQY001I %CSQ8 QUEUE MANAGER STARTING, USING PARAMETER MODULE CSQZPARM
CSQY022I %CSQ8 QUEUE MANAGER INITIALIZATION COMPLETE
CSQY002I %CSQ8 QUEUE MANAGER STOPPING

Start Date and Time

The STARTDA and STARTTI fields show the time this queue manager was most recently started, allowing a remote administrator to see the information which is otherwise only visible in the AMQERR01.LOG file.

On z/OS you can get the equivalent information by using the DISPLAY LOG command.

In MQ V9.3.2 the DISPLAY QMSTATUS command was enhanced with lots of additional information - read about that here.

So there you have it, another status command in your arsenal of tools for managing an MQ queue manager.

#Little-Gem
#IBMMQ
#IBMChampion