Summing your Accounting Data

Your can learn a lot about your applications by collecting and reviewing your IBM MQ Accounting data. In this post I want to show you an example of how you can get a view of your data when you have masses of it and can’t easily look at each individual record. I’ll show examples using both MO71 and MQSCX to view this data collected by MQEV. You can read this post by opening up the section for the tool you prefer to use.

The first and perhaps most obvious step when you have masses of accounting records is to add up all the records for the same application name. One of the reasons why you might have masses of accounting data records is because short lived applications cut a record at MQDISC time, so even if your accounting interval (ACCTINT) is 30 minutes, you might get 120 records for one application in that time if it connects 4 times each minute.

So here’s how to create a total for each application name.

Total up by Application name (MQSCX)

Issue a command like the following.

DISPLAY ACCTMQI(*) SUM(APPL) -INTVLEND CHANNEL CONNAME USERID ALLPUT

The output will be a list with one row for each unique application name.

N.B. If you’re wondering what the -INTVLEND is doing, I’m just trimming the display to show only what I need. Read this post for more about that.

ACCTMQI(Employee)     USERID(ppadams)  CHANNEL(HR.SVRCONN)   CONNAME(136.40.22.98) ALLPUT(3464)
ACCTMQI(ExtOrder)     USERID(*)        CHANNEL(PROC.SVRCONN) CONNAME(*)            ALLPUT(2927)
ACCTMQI(Invoice)      USERID(*)        CHANNEL(PROC.SVRCONN) CONNAME(*)            ALLPUT(8847)
ACCTMQI(Payroll)      USERID(*)        CHANNEL(PAYROLL.TLS)  CONNAME(136.40.22.98) ALLPUT(8342)
ACCTMQI(Work Order)   USERID(wrkadmin) CHANNEL(WORK.SVRCONN) CONNAME(134.23.19.20) ALLPUT(1218)
ACCTMQI(Work Request) USERID(*)        CHANNEL(WORK.SVRCONN) CONNAME(*)            ALLPUT(3727)

Total up by Application name (MO71)

Open up an MQ Event Accounting MQI List dialog and ensure the button to Sum by Appl is pressed.

The output will be a list with one row for each unique application name. I’ve used Alter List to change the columns I want to see.

Now you may see in the output that some of the fields, for example, the Connection Name field, contain an asterisk (‘*’). This means that the records which were totalled together contain different values. That is, the same application name connected to the queue manager from different IP addresses, i.e. different client machines. This is probably not at all surprising if the same application is used by many different people. As a result, you may well want to see a row per application name and the IP address it connected from. So let’s try that now.

Total up by Application name and IP address (MQSCX)

Issue a command like the following. This has one change from the command we previously issued, in that we have added the CONNAME field to list provided in the SUM attribute.

DISPLAY ACCTMQI(*) SUM(APPL,CONNAME) -INTVLEND CHANNEL CONNAME USERID ALLPUT

The output will be a list with one row for each unique combination of application name and connection name.

ACCTMQI(Employee)     USERID(ppadams)  CHANNEL(HR.SVRCONN)   CONNAME(136.40.22.98)  ALLPUT(3464)
ACCTMQI(ExtOrder)     USERID(djones)   CHANNEL(PROC.SVRCONN) CONNAME(137.46.28.126) ALLPUT(1473)
ACCTMQI(ExtOrder)     USERID(mjsmith)  CHANNEL(PROC.SVRCONN) CONNAME(137.46.28.128) ALLPUT(1454)
ACCTMQI(Invoice)      USERID(pwharper) CHANNEL(PROC.SVRCONN) CONNAME(137.46.28.67)  ALLPUT(2997)
ACCTMQI(Invoice)      USERID(djones)   CHANNEL(PROC.SVRCONN) CONNAME(137.46.28.126) ALLPUT(2949)
ACCTMQI(Invoice)      USERID(mjsmith)  CHANNEL(PROC.SVRCONN) CONNAME(137.46.28.128) ALLPUT(2901)
ACCTMQI(Payroll)      USERID(*)        CHANNEL(PAYROLL.TLS)  CONNAME(136.40.22.98)  ALLPUT(8342)
ACCTMQI(Work Order)   USERID(wrkadmin) CHANNEL(WORK.SVRCONN) CONNAME(134.23.19.20)  ALLPUT(1218)
ACCTMQI(Work Request) USERID(nsmith)   CHANNEL(WORK.SVRCONN) CONNAME(134.23.19.116) ALLPUT(434)
ACCTMQI(Work Request) USERID(khull)    CHANNEL(WORK.SVRCONN) CONNAME(134.23.19.114) ALLPUT(788)
ACCTMQI(Work Request) USERID(sjones)   CHANNEL(WORK.SVRCONN) CONNAME(134.23.19.112) ALLPUT(626)
ACCTMQI(Work Request) USERID(apbolt)   CHANNEL(WORK.SVRCONN) CONNAME(134.23.19.110) ALLPUT(1879)

Total up by Application name and IP address (MO71)

Ensure the button to Sum by Appl is pressed and also the button to Sum by Conname is pressed.

The output will be a list with one row for each unique application name and IP address combination.

We’ve got fewer asterisk (‘*’) characters in the output now, but still one row showing that the records totalled together contained different values for the User Identifier field. This shows that while the same application was being run from the same machine, it was run under different user IDs. To dig into that further we can change our totalling pattern a little further and include the user ID field. To reduce the output for the purposes of showing it here I’ll also just focus in on that one application in the next command.

Total up by Application name, IP address and User ID (MQSCX)

Issue a command like the following. This has two changes from the command we previously issued, in that we have added the USERID field to list provided in the SUM attribute, and we have restricted the application names returned to only those called 'Payroll'.

DISPLAY ACCTMQI('Payroll') SUM(APPL,CONNAME,USERID) -INTVLEND CHANNEL CONNAME USERID ALLPUT

The output will be a list with one row for each unique combination of application name, connection name and user ID.

ACCTMQI(Payroll) USERID(ppadams)  CHANNEL(PAYROLL.TLS) CONNAME(136.40.22.98) ALLPUT(581)
ACCTMQI(Payroll) USERID(payrlate) CHANNEL(PAYROLL.TLS) CONNAME(136.40.22.98) ALLPUT(1681)
ACCTMQI(Payroll) USERID(payradmn) CHANNEL(PAYROLL.TLS) CONNAME(136.40.22.98) ALLPUT(5911)

Total up by Application name, IP address and User ID (MO71)

Ensure the button to Sum by Appl is pressed, the button to Sum by Conname is pressed and the button to Sum by User is pressed. For this screenshot I have also limited the output to only the Payroll application that we are interested in.

The output will be a list with one row for each unique application name, IP address and User ID combination for the Payroll application.

As you can see, totalling up your MQ Accounting data can give you an easy way to see exactly what applications you have running against your queue manager, and where/how they are running, without the need to trawl through masses of individual records.

This concept can be very useful to answer all sorts of other questions. Consider the following options:

SUM() value	Meaning
APPL	Return a record for each Application Useful if you want to know what’s doing the most messaging etc
CHANNEL	Return a unique record for each Channel Useful for determining which channels are used the most and perhaps which are no-longer used.
USERID	Return a record for each unique Userid Useful for seeing who is doing what to your Queue Manager
RPRODUCT	Sum by remote product identifier Useful to know what remote clients are connected to your Queue Manager. Are people using JMS, C, .Net Java etc
APPL,RPRODUCT	Similar to the one above but now you get a record for each Application/Product combination. This is useful for seeing which applications are using which clients.
RVERSION	Sum by remote version number Useful to know what version of MQ Client people are using. For example, are people still using an old out of date product
APPL,RPRODUCT,RVERSION	Similar to the one above but now you get a record for each Application/Product Version combination. This is useful for seeing which applications are which version of client.
CONNAME	Sum by remote IP address Useful to know how many machine are connecting to you and where from.

Of course there are many more combinations and each combination has the potential to show you something interesting.

How can I view my message in hex?

In this post we cover how to view your message data as hex using MQGem tools as several of them offer this capability. Open up the twisty for each tool to read how to do this.

If you want to learn how to view your message data formatted, please read this post.

Using MO71

In MO71 you can browse a list of messages on a queue, then you can double click on a message from the list, to view the whole message individually. To view the message data in hex, either:

• Select the “Hex Message” button on the toolbar
  
• From the right-mouse-click context menu choose Display Format → Hex Message

Displaying a message in hex in MO71 – ASCII column on right hand side

If you don’t wish to see the “ASCII column” (that is, the “character representation” of the hex data, it might be EBCDIC or ASCII) to the right of the hex data as is shown in the above screen shot, then you can turn this off using the right-mouse-click context menu and unchecking the Display Format → Ascii Column option.

Using the Q program

In the Q program, you can request that your message data be shown in hex using the -dh flag. For example:

q -m MQG1 -iPRODUCT.DATA -dh

Which will display your message data as follows:

Connecting ...connected to 'MQG1'.
===============================================================================
+00000000 3C50726F 64756374 3E3C4E61 6D653E4D 4F37313C  <Product><Name>MO71<
+00000014 2F4E616D 653E3C57 65627061 67653E68 74747073  /Name><Webpage>https
+00000028 3A2F2F77 77772E6D 7167656D 2E636F6D 2F6D6F37  ://www.mqgem.com/mo7
+0000003C 312E6874 6D6C3C2F 57656270 6167653E 3C506C61  1.html</Webpage><Pla
+00000050 74666F72 6D733E3C 506C6174 666F726D 3E57696E  tforms><Platform>Win

Using MQEdit

In MQEdit you can browse a list of messages on a queue, then you can double click on a message from the list, to view the whole message individually. To view the message data in hex, either:

• Select the “Hex Message” button on the toolbar
  
• From the right-mouse-click context menu choose Display Format → Hex Message

Displaying a message in hex in MQEdit – ASCII column on right hand side

---

If you don’t have any of these tools, but would like to try any or all of them out, please contact support@mqgem.com and a 1-month trial licence will be sent to you with no obligation to buy. You can download the tools from our website.

I want my view my message formatted

In this post we cover how to view your message data formatted out using MQGem tools as several of them offer this capability. Open up the twisty for each tool to read how to do this.

If you want to learn how to view your message data in hex, please read this post.

Using MO71

In MO71 you can browse a list of messages on a queue, then you can double click on a message from the list, to view the whole message individually. To view the message data formatted, either:

• Select the “Formatted Message” button on the toolbar
  
• From the right-mouse-click context menu choose Display Format → Formatted Message

Displaying a formatted message in MO71 – Low Level detail in use

MO71 will recognise and format out all the built-in MQ formats as well as providing some additional formatting options for XML. Check out all the options in the Display Format menu mentioned above. Some message formats will benefit further from the High/Medium/Low display options. The above screenshot is showing a PCF event message using Low detail.

Using the Q program

In the Q program, you can request that your message data be shown formatted using the -df flag. High/Medium/Low detail can also be chosen by adding 3,2, or 1 respectively onto the end of the flag. For example:

q -m MQG1 -iMY.EVENTS -df1

Which will display your message data as follows:

Connecting ...connected to 'MQG1'.
===============================================================================
[  244 bytes] Message Content
Command      :44 (QMgr Event)
Reason       :2035 (Not authorized)
Parameter Id :2015 (Queue Manager Name)
Value        :'MQG1                                            '
Parameter Id :1020 (Reason Qualifier)
Value        :1 [0x'1'] MQRQ_CONN_NOT_AUTHORIZED
Parameter Id :3025 (User Identifier)
Value        :'mqgusr1     '
Parameter Id :3206 (CSP User Identifier)
Value        :'mqgusr1'
Parameter Id :1 (Application Type)
Value        :11 [0x'B'] MQAT_WINDOWS_NT
Parameter Id :3024 (Application Name)
Value        :'d:\nttools\q.exe            '
------------------------------------------------------ Command (QMgr Event) --

The Q program will recognise and format out all the built-in MQ formats as well as CSV, FIX, JSON, XML and EDIFACT. Some message formats will benefit further from the High/Medium/Low display options. The above output is showing a PCF event message using Low detail.

Using MQEdit

In MQEdit you can browse a list of messages on a queue, then you can double click on a message from the list, to view the whole message individually. To view the message data in hex, either:

• Select the “Formatted Message” button on the toolbar
  
• From the right-mouse-click context menu choose Display Format → Formatted Message

Displaying a formatted message in MQEdit – Low Level detail in use

MQEdit will recognise and format out all the built-in MQ formats as well as CSV, FIX, JSON, XML and EDIFACT. In addition it can format out your own messages formats as well. For more on that read User Formats in MQEdit. Some message formats will benefit further from the High/Medium/Low display options. The above output is showing a PCF event message using Low detail.

---

If you don’t have any of these tools, but would like to try any or all of them out, please contact support@mqgem.com and a 1-month trial licence will be sent to you with no obligation to buy. You can download the tools from our website.

QLOAD: Using Non-QLOAD input files

We have just updated QLOAD with a couple of minor enhancements to improve your experience when using non-QLOAD files as input.

The ability to use non-QLOAD files as input to QLOAD has been around for a while, you can read more about it here. We have now enhanced this feature to allow it to operate with indexed file names which were already available for QLOAD-files.

An indexed file name is one with either %n or %N in the file name.

n	Current File number
N	Current File number padded to 5 characters eg.000001

So imagine you have a set of files, thus:-

msgs1.txt
msgs2.txt
msgs3.txt
msgs4.txt
msgs5.txt
msgs6.txt

each containing one or more messages, delimited say by XML tags. You can now present those files to QLOAD with the following command.

qload -m MQG1 -o Q1 -f msgs%n.txt -Cd -nns:"<msg>" -nne:"</msg>"

QLOAD will read through the files and prior to putting the messages, will report what it found and check that this is what you expected.

Loading 'msgs1.txt' : 4 messages found
Loading 'msgs2.txt' : 2 messages found
Loading 'msgs3.txt' : 2 messages found
Loading 'msgs4.txt' : 2 messages found
Loading 'msgs5.txt' : 3 messages found
Loading 'msgs6.txt' : 3 messages found
Do you want to continue? (y/n)

In addition to allowing multiple non-QLOAD files to be processed in one command, we have also added some over-rides for Message Descriptor (MQMD) attributes.

When you use QLOAD files, the MQMD attributes are all saved away in the file to allow you to reload the messages exactly as they were. If you need to you can edit the MQMD attributes to change these values before reloading.

When you use non-QLOAD files there are no MQMD attributes in the files and you would just get a default MQMD put to the queue with the message data.

With this new enhancement, you can set a number of the MQMD attributes when you put the data from your non-QLOAD file, or indeed over-ride the data in the QLOAD file to save you having to make numerous edits.

Here’s an example of loading up our multiple files and setting the reply-to-queue in the MQMD. This also sets the message type to MQMT_REQUEST as well.

qload -m MQG1 -o Q1 -f msgs%n.txt -Cd -nns:"<msg>" -nne:"</msg>" -Ar:MY.REPLY.Q

If we look at the message descriptor of the message we just put it looks like this:

[  324 bytes] Message Descriptor (MQMD)
Report       :00000000
Message Type :1 (Request msg)
Format       :'MQSTR   ' (String)
Priority     :2 (Low)
Persistence  :0 (Not Persistent)
Message Id   :414D51204D514731202020202020202037C10B650FF80140
              A M Q   M Q G 1                 7 ┴ . e . ° . @
ReplyToQ     :'MY.REPLY.Q                                      '
ReplyToQMgr  :'MQG1                                            '

The full set of MQMD attributes that you can set is as follows:

flag	MQMD Attribute
-Ac:<ccsid>	Message Codepage
-Ae:<expiry>	Message Expiry (in tenths of a second)
-Af:<format>	Message Format
-Ap:<priority>	Message Priority
-Ar:<ReplyQ>	Message Reply Queue and optionally Reply Queue Manager
	-Ar:REPLYQ
	-Ar:QM1/REPLYQ
-At:<Msg Type>	Message Type: REQUEST, REPLY, DATAGRAM, REPORT

We hope this will allow you to use QLOAD to load up your message content that is currently held in files, into queues on your queue manager.

---

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.

A new way to make TOP for MQ

Many years back, one of our early sample MQSCX scripts was called top. It did for MQ queues, what the top command on Linux does for processes. It would display the list of the queues sorted by their depth, with the queue with the most messages at the top of the display. It was a simple illustration of retrieving information from the MQ Command server, using arrays and using the built-in sort function. It also illustrated a system variable _height allowing you to only write as many lines as it would take to fill the screen.

Queue Name                                       Depth
==========                                       =====
MQGEM.MQEV.DATA.QUEUE                             2436
SYSTEM.AUTH.DATA.QUEUE                             340
SYSTEM.ADMIN.TRACE.ACTIVITY.QUEUE                   73
SYSTEM.ADMIN.ACCOUNTING.QUEUE                       42
SYSTEM.RETAINED.PUB.QUEUE                           29
SYSTEM.CHANNEL.SYNCQ                                19
SYSTEM.CHLAUTH.DATA.QUEUE                           17
SYSTEM.ADMIN.CONFIG.EVENT                           16
SYSTEM.ADMIN.STATISTICS.QUEUE                       12
SYSTEM.PROTECTION.POLICY.QUEUE                       8

Now in this latest version of MQSCX, what that script did can be achieved (apart from pretty column titles) with a single command. This illustrates almost all the new features introduced in this new version of MQSCX in one fell swoop. Let’s build up the command gradually.

We start with a command to list all the local queues that have some messages on them (utilising the IBM MQ WHERE clause to reduce the number of messages we get sent as a result of this command).

DISPLAY QLOCAL(*) WHERE(CURDEPTH GT 0)

Now we note that the TYPE (and if on z/OS the QSGDISP) attributes are not adding anything useful to the display so we remove them. Read more about command modifiers and creating concise output reports here.

DISPLAY QLOCAL(*) WHERE(CURDEPTH GT 0) -TYPE,QSGDISP

Now we need to sort the list so that the queues with the most messages are at the top of the display. Read more about sorting your DISPLAY command output here.

DISPLAY QLOCAL(*) WHERE(CURDEPTH GT 0) -TYPE,QSGDISP =SORTD(CURDEPTH)

And finally, in case our list of queues is longer than can fit into a single screenful, we limit the number of responses accordingly, using the _height system variable. Read more about limiting the number of responses here.

DISPLAY QLOCAL(*) WHERE(CURDEPTH GT 0) -TYPE,QSGDISP =SORTD(CURDEPTH) =MAXRESP(<_height-3>)

QUEUE(MQGEM.MQEV.DATA.QUEUE)             CURDEPTH(2436)
QUEUE(SYSTEM.AUTH.DATA.QUEUE)            CURDEPTH(340)
QUEUE(SYSTEM.ADMIN.TRACE.ACTIVITY.QUEUE) CURDEPTH(75)
QUEUE(SYSTEM.ADMIN.ACCOUNTING.QUEUE)     CURDEPTH(44)
QUEUE(SYSTEM.RETAINED.PUB.QUEUE)         CURDEPTH(29)
QUEUE(SYSTEM.CHANNEL.SYNCQ)              CURDEPTH(19)
QUEUE(SYSTEM.CHLAUTH.DATA.QUEUE)         CURDEPTH(17)
QUEUE(SYSTEM.ADMIN.CONFIG.EVENT)         CURDEPTH(16)
QUEUE(SYSTEM.ADMIN.STATISTICS.QUEUE)     CURDEPTH(14)
QUEUE(SYSTEM.PROTECTION.POLICY.QUEUE)    CURDEPTH(8)

And there you have a single command, providing you with the top queues by depth. Of course, you can build up other commands in this same way for all your favourite output.

One advantage this has over the script mechanism, is that you can do one other thing that the Linux top command does, which is to repeat the command every n seconds. Just put the whole command into an =repeat instruction and it will update the screen in place (because the lines are command output lines rather than lines printed to the screen).

=repeat cmd(DISPLAY QLOCAL(*) WHERE(CURDEPTH GT 0) -TYPE,QSGDISP =SORTD(CURDEPTH) =MAXRESP(<_height-3>)) delay(5)

---

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.

Responding QMgr from CMDSCOPE(*) command

When you issue a CMDSCOPE(*) command to your Queue Sharing Group (QSG), responses will be returned from each member queue manager. The MQSC output looks something like the following (some spaces removed for brevity). You get a header and footer to tell you what happened with your command (shown in the red boxes), and a set of responses (in this case just 2 queues from each) from each of the member queue managers (shown in the green boxes).

=set formatting(off) distotals(off)
[17:58:57] DISPLAY QLOCAL(Q*) CMDSCOPE(*) CURDEPTH
CSQN205I   COUNT=       2, RETURN=00000000, REASON=00000004
CSQN137I +CSQ1 'DISPLAY QLOCAL' command accepted for CMDSCOPE(*), sent to 3
CSQN205I   COUNT=       5, RETURN=00000000, REASON=00000000
CSQN121I +CSQ1 'DISPLAY QLOCAL' command responses from CSQ1
CSQM401I +CSQ1 QUEUE(Q1    ) TYPE(QLOCAL ) QSGDISP(QMGR   ) CURDEPTH(         5)
CSQM401I +CSQ1 QUEUE(Q2    ) TYPE(QLOCAL ) QSGDISP(QMGR   ) CURDEPTH(         0)
CSQ9022I +CSQ1 CSQMDRTS ' DISPLAY QLOCAL' NORMAL COMPLETION
CSQN205I   COUNT=       5, RETURN=00000000, REASON=00000000
CSQN121I +CSQ2 'DISPLAY QLOCAL' command responses from CSQ2
CSQM401I +CSQ2 QUEUE(Q1    ) TYPE(QLOCAL ) QSGDISP(QMGR   ) CURDEPTH(        27)
CSQM401I +CSQ2 QUEUE(Q2    ) TYPE(QLOCAL ) QSGDISP(QMGR   ) CURDEPTH(         3)
CSQ9022I +CSQ2 CSQMDRTS ' DISPLAY QLOCAL' NORMAL COMPLETION
CSQN205I   COUNT=       5, RETURN=00000000, REASON=00000000
CSQN121I +CSQ3 'DISPLAY QLOCAL' command responses from CSQ3
CSQM401I +CSQ3 QUEUE(Q1    ) TYPE(QLOCAL ) QSGDISP(QMGR   ) CURDEPTH(         1)
CSQM401I +CSQ3 QUEUE(Q2    ) TYPE(QLOCAL ) QSGDISP(QMGR   ) CURDEPTH(         0)
CSQ9022I +CSQ3 CSQMDRTS ' DISPLAY QLOCAL' NORMAL COMPLETION
CSQN205I   COUNT=       2, RETURN=00000000, REASON=00000000
CSQN122I +CSQ1 'DISPLAY QLOCAL' command for CMDSCOPE(*) normal completion

We were implementing the new sorting feature in MQSCX, and it became quite apparent that the MQSC responses did not hold all the important information. Looking at the output above, it is clear that the responding queue manager name is not part of the queue object response but rather it is part of the surrounding messages. When the responses from multiple queue managers from a Queue Sharing Group (QSG) were sorted we would lose the information about which queue manager it came from.

Message CSQM401I shows a Queue Manager name?

“I can see your queue manager name in the queue details message, CSQM401I, why can’t you use that?”

CSQM401I +CSQ2 QUEUE(Q1) TYPE(QLOCAL) QSGDISP(QMGR) CURDEPTH(27)

The text “+CSQ2” that you can see in the above message is not actually the queue manager name, but in fact the queue manager’s command prefix. This is the string you type prefixing a command in SDSF to ensure the command is sent to the correct sub-system. Often, by convention, it is a string that contains the queue manager name, usually prefixed with some punctuation character, but it is not always so. I have used command prefixes that were just “!M” for a queue manager name of 4-characters. The actual queue manager name is provided in message CSQN121I and that is what we need to use.

CSQN121I +CSQ2 'DISPLAY QLOCAL' command responses from CSQ2

So there is a new, constructed, response variable in the latest version of MQSCX. It is called QSGQM and it holds the responding queue manager name. So let’s now look at the formatted version of the above command. I’ve also switched on the displaying of totals, which in the case of multiple queue manager responses from a QSG, provides a subtotal count as well as an overall count.

=set formatting(on) distotals(on)
[18:16:44] DISPLAY QLOCAL(Q*) CMDSCOPE(*) CURDEPTH
QSGQM(CSQ1) QUEUE(Q1) TYPE(QLOCAL) QSGDISP(QMGR) CURDEPTH(5)
QSGQM(CSQ1) QUEUE(Q2) TYPE(QLOCAL) QSGDISP(QMGR) CURDEPTH(0)
Subtotal display responses - Received:2
QSGQM(CSQ2) QUEUE(Q1) TYPE(QLOCAL) QSGDISP(QMGR) CURDEPTH(27)
QSGQM(CSQ2) QUEUE(Q2) TYPE(QLOCAL) QSGDISP(QMGR) CURDEPTH(3)
Subtotal display responses - Received:2
QSGQM(CSQ3) QUEUE(Q1) TYPE(QLOCAL) QSGDISP(QMGR) CURDEPTH(1)
QSGQM(CSQ3) QUEUE(Q2) TYPE(QLOCAL) QSGDISP(QMGR) CURDEPTH(0)
Subtotal display responses - Received:2
Total display responses - Received:6

Now if we want to sort the responses coming back from multiple queue managers in a QSG we are not going to lose the information about which queue manager the response was from.

=set formatting(on) distotals(on)
[18:16:44] DISPLAY QLOCAL(Q*) CMDSCOPE(*) =SORTD(CURDEPTH)
QSGQM(CSQ2) QUEUE(Q1) TYPE(QLOCAL) QSGDISP(QMGR) CURDEPTH(27)
QSGQM(CSQ1) QUEUE(Q1) TYPE(QLOCAL) QSGDISP(QMGR) CURDEPTH(5)
QSGQM(CSQ2) QUEUE(Q2) TYPE(QLOCAL) QSGDISP(QMGR) CURDEPTH(3)
QSGQM(CSQ3) QUEUE(Q1) TYPE(QLOCAL) QSGDISP(QMGR) CURDEPTH(1)
QSGQM(CSQ3) QUEUE(Q2) TYPE(QLOCAL) QSGDISP(QMGR) CURDEPTH(0)
QSGQM(CSQ1) QUEUE(Q2) TYPE(QLOCAL) QSGDISP(QMGR) CURDEPTH(0)
Total display responses - Received:6

As you can see, with this type of display, the subtotal lines are removed since the responses are no longer grouped together by the responding queue manager so they don’t make sense anymore.

In addition to enabling sorted displays to operate across a Queue Sharing Group, the introduction of QSGQM is helpful in other situations too.

When using a CMDSCOPE(*) command within a foreach loop you can now tell which member queue manager the response came from because the QSGQM response variable is available to you there too. Here’s a very small example.

foreach(DISPLAY QLOCAL(Q*) =SORTD(CURDEPTH) CMDSCOPE(*))
  print "Queue", QUEUE, "on QMgr", QSGQM, "has", CURDEPTH, "messages"
endfor

And in fact anywhere in your scripting where you use CMDSCOPE(*) commands, the queue manager name is now available as a response variable.

We hope this will make interacting with your Queue Sharing Group more easily scriptable.

---

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.

Limiting Display Output

A new clause is now available in the latest version of MQSCX to limit the number of responses that are displayed on the screen. This is very similar to the parameter that MQEV has on its commands to limit the number of responses that the MQEV command server produces, since you can have a very large number of responses if you use accounting records as an example. In MQSCX, this is only able to affect the display side of things. It can’t, unfortunately, stop the MQ command server from producing the responses.

You can use this clause, very simply, to reduce the displayed responses to the first, say 50, responses as follows:

DISPLAY QLOCAL(*) =MAXRESP(50)

Of course, this is more useful if you have filtered your display in some way, or perhaps sorted it. For example, to find the 10 queues with most messages on them.

DISPLAY QLOCAL(*) WHERE(CURDEPTH GT 0) =SORTD(CURDEPTH) =MAXRESP(10)

Explanation of WHERE clause

There is one way to reduce the number of responses that the IBM MQ command server sends you and that is the MQ WHERE clause. In this example, since we are only interested in the queues with most messages, all the empty queues will be sorted to the bottom, and likely not shown at all due to the limit of 10 responses, so we can tell the IBM MQ command server not to send them in the first place.

It might also be useful to combine a sorting clause with a limit of only a single response. For example, if you wish to find the maximum value of an attribute in use, you might use a command like this to discover the biggest value used for MAXMSGL on a queue or a channel.

DISPLAY QLOCAL(*) =SORTD(MAXMSGL) =MAXRESP(1)

DISPLAY CHANNEL(*) =SORTD(MAXMSGL) =MAXRESP(1)

Another useful trick, for interactive commands, might be to request only the number of responses that fit into a screenful. You can do that by using the _height system variable. I tend to subtract a few lines from it to accommodate the command entry area at the bottom, and to allow space for the command I have entered to still be visible at the top of the screen where it acts rather like a title.

DISPLAY QLOCAL(*) =SORTD(CURDEPTH) =MAXRESP(<_height-3>)

[22:23:10] DISPLAY QLOCAL(*) =SORTD(CURDEPTH) =MAXRESP(15)

QUEUE(SYSTEM.ADMIN.TRACE.ACTIVITY.QUEUE) TYPE(QLOCAL) CURDEPTH(915)

QUEUE(SYSTEM.AUTH.DATA.QUEUE) TYPE(QLOCAL) CURDEPTH(346)

QUEUE(SYSTEM.RETAINED.PUB.QUEUE) TYPE(QLOCAL) CURDEPTH(29)

QUEUE(APP.PRC.INQUIRY.QUEUE) TYPE(QLOCAL) CURDEPTH(20)

QUEUE(SYSTEM.CHANNEL.SYNCQ) TYPE(QLOCAL) CURDEPTH(19)

QUEUE(SYSTEM.ADMIN.CONFIG.EVENT) TYPE(QLOCAL) CURDEPTH(18)

QUEUE(SYSTEM.CHLAUTH.DATA.QUEUE) TYPE(QLOCAL) CURDEPTH(17)

QUEUE(APP.PRC.UPDATE.QUEUE) TYPE(QLOCAL) CURDEPTH(15)

QUEUE(SYSTEM.ADMIN.COMMAND.EVENT) TYPE(QLOCAL) CURDEPTH(13)

QUEUE(APP.ORD.COMPLETE.QUEUE) TYPE(QLOCAL) CURDEPTH(11)

QUEUE(APP.ORD.PROCESS.QUEUE) TYPE(QLOCAL) CURDEPTH(9)

QUEUE(SYSTEM.PROTECTION.POLICY.QUEUE) TYPE(QLOCAL) CURDEPTH(8)

QUEUE(APP.ORD.UPDATE.QUEUE) TYPE(QLOCAL) CURDEPTH(3)

QUEUE(APP.ORD.CREATE.QUEUE) TYPE(QLOCAL) CURDEPTH(2)

Total display responses – Received:181 Shown:15/181

MQG1>

At the bottom of the screen output shown above you’ll also see an example of the updated display totals output. You see this line if you use the following setting.

=set distotals(on)

It has three different sections which may or may not be displayed. If you have no filtering or limiting applied at all, you will just see:

Total display responses – Received:181

If you have an MQSCX =WHERE clause, a wildcard, or an =FIND clause, reducing what is displayed by matching against particular things, you will see:

Total display responses – Received:181 Matched:23/181

And finally if you also have an MQSCX =MAXRESP clause reducing what is shown by limiting the display, you will see:

Total display responses – Received:181 Matched:23/181 Shown:15/23

By default in MQSCX, =MAXRESP is unlimited unless you provide a number. However, you can set a value to be used to limit the number of response displayed for every command if you wish, with the following setting.

=set defmaxresp(unlimited | integer)

---

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.

Displaying MQSC data in columns

MQSCX has always displayed your MQSC data in columns. One of its early goals was to make better use of screen real estate than runmqsc. It did this by choosing to display the MQSC data in more than two columns. In fact it would use as many columns as fitted into your screen width.

runmqsc two column output

AMQ8409I: Display Queue details.
   QUEUE(Q1)                               TYPE(QLOCAL)
   ACCTQ(QMGR)                             ALTDATE(2023-08-22)
   ALTTIME(10.27.26)                       BOQNAME( )
   BOTHRESH(0)                             CLUSNL( )
   CLUSTER( )                              CLCHNAME( )
   CLWLPRTY(0)                             CLWLRANK(0)
   CLWLUSEQ(QMGR)                          CRDATE(2019-06-19)
   CRTIME(18.29.19)                        CURDEPTH(0)
   CUSTOM( )                               DEFBIND(OPEN)
   DEFPRTY(0)                              DEFPSIST(NO)
   DEFPRESP(SYNC)                          DEFREADA(NO)
   DEFSOPT(SHARED)                         DEFTYPE(PREDEFINED)
   DESCR( )                                DISTL(NO)
   GET(ENABLED)                            HARDENBO
   IMGRCOVQ(QMGR)                          INITQ( )
   IPPROCS(0)                              MAXDEPTH(5000)
   MAXMSGL(4194304)                        MAXFSIZE(DEFAULT)
   MONQ(HIGH)                              MSGDLVSQ(PRIORITY)
   NOTRIGGER                               NPMCLASS(NORMAL)
   OPPROCS(0)                              PROCESS( )
   PUT(ENABLED)                            PROPCTL(COMPAT)
   QDEPTHHI(80)                            QDEPTHLO(20)
   QDPHIEV(DISABLED)                       QDPLOEV(DISABLED)
   QDPMAXEV(ENABLED)                       QSVCIEV(NONE)
   QSVCINT(999999999)                      RETINTVL(999999999)
   SCOPE(QMGR)                             SHARE
   STATQ(QMGR)                             STREAMQ( )
   STRMQOS(BESTEF)                         TRIGDATA( )
   TRIGDPTH(3)                             TRIGMPRI(0)
   TRIGTYPE(FIRST)                         USAGE(NORMAL)

MQSCX uses number of columns that will fit the screen width

AMQ8409I: Display Queue details.
QUEUE(Q1)           TYPE(QLOCAL)        ACCTQ(QMGR)         ALTDATE(2023-08-22)
ALTTIME(10.27.26)   BOQNAME( )          BOTHRESH(0)         CLUSNL( )
CLUSTER( )          CLCHNAME( )         CLWLPRTY(0)         CLWLRANK(0)
CLWLUSEQ(QMGR)      CRDATE(2019-06-19)  CRTIME(18.29.19)    CURDEPTH(0)
CUSTOM( )           DEFBIND(OPEN)       DEFPRTY(0)          DEFPSIST(NO)
DEFPRESP(SYNC)      DEFREADA(NO)        DEFSOPT(SHARED)     DEFTYPE(PREDEFINED)
DESCR( )            DISTL(NO)           GET(ENABLED)        HARDENBO
IMGRCOVQ(QMGR)      INITQ( )            IPPROCS(0)          MAXDEPTH(5000)
MAXMSGL(4194304)    MAXFSIZE(DEFAULT)   MONQ(HIGH)          MSGDLVSQ(PRIORITY)
NOTRIGGER           NPMCLASS(NORMAL)    OPPROCS(0)          PROCESS( )
PUT(ENABLED)        PROPCTL(COMPAT)     QDEPTHHI(80)        QDEPTHLO(20)
QDPHIEV(DISABLED)   QDPLOEV(DISABLED)   QDPMAXEV(ENABLED)   QSVCIEV(NONE)
QSVCINT(999999999)  RETINTVL(999999999) SCOPE(QMGR)         SHARE
STATQ(QMGR)         STREAMQ( )          STRMQOS(BESTEF)     TRIGDATA( )
TRIGDPTH(3)         TRIGMPRI(0)         TRIGTYPE(FIRST)     USAGE(NORMAL)

This style of columns is still available in MQSCX, but in the latest version there is now a new style of column that you can use. One of the issues that led us to introduce a new style of columnar display is what happens when you have data in the same column, say the queue name, of hugely varying lengths. Here’s an example.

QUEUE(SYSTEM.ADMIN) TYPE(QLOCAL)
QUEUE(SYSTEM.ADMIN.QMGR.EVENT)          TYPE(QLOCAL)
QUEUE(SYSTEM.ADMIN.STATISTICS.QUEUE)    TYPE(QLOCAL)
QUEUE(SYSTEM.ADMIN.TRACE.ACTIVITY.QUEUE)                 TYPE(QLOCAL)
QUEUE(SYSTEM.ADMIN.TRACE.ROUTE.QUEUE)   TYPE(QLOCAL)

As you can see the short queue name has the next attribute further to the left, and the extra long queue name pushes the next attribute out to a further right column.

To fix these types of display quirks, we have introduced a new column style that is based on the size of the content being displayed, rather than on fixed column sizes. With this setting, the above queue list, now looks like this with all the columns perfectly lined up.

QUEUE(SYSTEM.ADMIN)                      TYPE(QLOCAL)
QUEUE(SYSTEM.ADMIN.QMGR.EVENT)           TYPE(QLOCAL)
QUEUE(SYSTEM.ADMIN.STATISTICS.QUEUE)     TYPE(QLOCAL)
QUEUE(SYSTEM.ADMIN.TRACE.ACTIVITY.QUEUE) TYPE(QLOCAL)
QUEUE(SYSTEM.ADMIN.TRACE.ROUTE.QUEUE)    TYPE(QLOCAL)

Two column styles but three settings?

To make your choice of these column styles, there is a setting to use as follows.

=set colstyle( fixed | auto | content )

It has, as you can see, three values, even though there are only two styles! The default value, shown by the underlined option above, is called “auto” and uses the “content” style when the output is short enough to fit on one line, and uses the “fixed” style when the output gets longer and wraps onto two or more lines. We chose to do this because the lined-up display is really marvellous in the one line setting, and we’re not sure that anyone would want to go back to the fixed display there, but fixed style may be more familiar when you start getting multiple lines of output per response.

Content column style over multiple lines

The aim of the content column style is that the same attribute is always at the same place on the screen width-wise. This is quite obvious when you have one line per response because it makes a nice neat column. What does it mean when you have responses that span multiple lines? Well, it still means the same thing, that the same attribute is always at the same place on the screen width-wise. Have you ever looked at a big screen full of MQSC data and found an attribute for the first object definition, and then not been able to find it in the second object definition because it’s moved a bit due to some long string attributes changing where everything goes?

Content column style means that once you find the attribute you are looking for you can use your finger (or your cursor) and move down the screen and the same attribute is ALWAYS in the same width-wise position.

Examples are probably the best way to show what I mean so below are the same output in runmqsc vs MQSCX with content style columns.

runmqsc shifting attribute positions

AMQ8414I: Display Channel details.
   CHANNEL(MQGEM.TLS.SVRCONN)              CHLTYPE(SVRCONN)
   SSLCIPH(ANY_TLS12)                      SSLPEER(CN=Morag)
AMQ8414I: Display Channel details.
   CHANNEL(MQGEM101.SSL)                   CHLTYPE(SVRCONN)
   SSLCIPH(TLS_RSA_WITH_AES_128_CBC_SHA256)
   SSLPEER(CN=Morag)

MQSCX attribute in same position

AMQ8414I: Display Channel details.
CHANNEL(MQGEM.TLS.SVRCONN) CHLTYPE(SVRCONN)
SSLCIPH(ANY_TLS12)                       SSLPEER(CN=Morag)
AMQ8414I: Display Channel details.
CHANNEL(MQGEM101.SSL)      CHLTYPE(SVRCONN)
SSLCIPH(TLS_RSA_WITH_AES_128_CBC_SHA256) SSLPEER(CN=Morag)

---

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.

Sorting DISPLAY command output

In the latest version of MQSCX, you can sort the output of your DISPLAY commands with an extra clause on the DISPLAY command.

Here’s a simple example.

DISPLAY QLOCAL(*) =SORTD(CURDEPTH)

You can use this with numeric attributes such as the example above, or with string or enumerated attributes.

This example will sort all the transmission queues together.

DISPLAY QLOCAL(*) =SORT(USAGE)

This example will sort all your Cipher Specs into alphabetical order.

DISPLAY CHANNEL(*) =SORT(SSLCIPH)

A sort clause doesn’t just have to be a single attribute however, it can be any expression. So for example, you might want to sort your running channels by the time of the last message sent. This is conveyed by MQ in two fields, LSTMSGDA and LSGMSGTI. You can concatenate these two string attributes in a sort clause as follows to show the most recent channels moving messages to the top. This also illustrates using command modifiers to get only the fields you want to see.

DISPLAY CHSTATUS(*) =SORTD(LSTMSGDA+LSTMSGTI) ‑ALL +CHANNEL,RQMNAME,LSTMSGDA,LSTMSGTI

CHANNEL(TO.QM3) LSTMSGDA(2023-08-22) LSTMSGTI(17.05.52) RQMNAME(QM3)
CHANNEL(TO.QM4) LSTMSGDA(2023-08-22) LSTMSGTI(17.05.52) RQMNAME(QM4)
CHANNEL(TO.QM2) LSTMSGDA(2023-08-22) LSTMSGTI(17.05.52) RQMNAME(QM2)
CHANNEL(TO.QM1) LSTMSGDA(2023-08-22) LSTMSGTI(17.05.17) RQMNAME(QM4)
CHANNEL(TO.QM1) LSTMSGDA(2023-08-22) LSTMSGTI(17.05.17) RQMNAME(QM2)
CHANNEL(TO.QM1) LSTMSGDA(2023-08-22) LSTMSGTI(17.05.14) RQMNAME(QM3)

Or you might be interested in the depth of queues, but rather than the number of messages, you want to see the fullness of the queue, i.e. you want to see the queue that is getting closest to being full. To do this you might use the following command.

DISPLAY QLOCAL(*) =SORTD(CURDEPTH/MAXDEPTH)

Sorting strings – order

When you are sorting string attributes, the case of the sort order might matter to you. You have the choice to have a case sensitive sort where capital letters are sorted first followed by lower case letters. Or you can have the MQSCX sort order which puts all the A’s together, A’s and then a’s, and all the B’s together etc. Of course, if you make all your object names in upper case you won’t case about this.

Use =set cssort( off | on ) to chose what you need.

foreach loops

Since you can put the sort clauses on your DISPLAY command, this means that you can also use them in a foreach loop. This means that your script can work on the data already sorted the way you need it, which is very handy.

* Create an array of queue names and their curdepths
foreach(DISPLAY QLOCAL(*) WHERE(CURDEPTH GT 0) =SORTD(CURDEPTH))
  @val[1,_idxEach] = QUEUE
  @val[2,_idxEach] = CURDEPTH
endfor

I’ve just given you a few examples of things you might want to sort in this blog post. I’m sure you can think of many more.

---

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.

Viewing only what you need

I do like a concise display when I am making MQSC enquiries of my queue manager. I find it helps to ensure the report is correct, and the output is clear if it only shows what you need to see and nothing spurious.

This is often not possible though because of the attributes that MQ deems necessary to return to you. There are many examples, a few of which follow to illustrate what I mean.

Applications connected to my Queue Manager

If I want to see a quick snapshot of the applications connected to my queue manager I can use the DISPLAY CONN(*) WHERE(APPLTYPE EQ USER) command. This will show me the connection IDs and not a lot else by default:-

CONN(8D08D86400E00040) EXTCONN(414D5143514D31202020202020202020) TYPE(CONN) APPLTYPE(USER)
CONN(8D08D864007F0240) EXTCONN(414D5143514D31202020202020202020) TYPE(CONN) APPLTYPE(USER)
CONN(8D08D86400E10040) EXTCONN(414D5143514D31202020202020202020) TYPE(CONN) APPLTYPE(USER)
CONN(8D08D86400800240) EXTCONN(414D5143514D31202020202020202020) TYPE(CONN) APPLTYPE(USER)

Really what I want to see is the name of the application, and perhaps the user ID it is running with, so I add those two attributes to my command.

DISPLAY CONN(*) WHERE(APPLTYPE EQ USER) APPLTAG USERID

And now I have output like the following because the answer has got too long to fit on a single line per response.

AMQ8276I: Display Connection details.
CONN(8D08D86400E00040)               EXTCONN(414D5143514D31202020202020202020)   TYPE(CONN)
APPLTAG(MQGem Software MO71)         APPLTYPE(USER)      USERID(mqgemusr)
AMQ8276I: Display Connection details.
CONN(8D08D864007F0240)               EXTCONN(414D5143514D31202020202020202020)   TYPE(CONN)
APPLTAG(MQGem Software MQSCX)        APPLTYPE(USER)      USERID(mqgemusr)
AMQ8276I: Display Connection details.
CONN(8D08D86400E10040)               EXTCONN(414D5143514D31202020202020202020)   TYPE(CONN)
APPLTAG(MQGem Software MO71)         APPLTYPE(USER)      USERID(mqgemusr)
AMQ8276I: Display Connection details.
CONN(8D08D86400800240)               EXTCONN(414D5143514D31202020202020202020)   TYPE(CONN)
APPLTAG(MQGem Software MQSCX)        APPLTYPE(USER)      USERID(mqgemusr)

Much of this output is taken up showing me the connection IDs, which are actually not interesting when what I’m after is the application names. To make this display more concise, I’d like to be able to remove those attributes that I didn’t actually ask for. Command modifiers in MQSCX is a new feature that allows you to do just that. I can enhance the above command as follows:-

DIS CONN(*) WHERE(APPLTYPE EQ USER) APPLTAG USERID -CONN,EXTCONN,TYPE

and now my output looks like this – back to a single line per response.

APPLTAG(MQGem Software MO71)  APPLTYPE(USER) USERID(mqgemusr)
APPLTAG(MQGem Software MQSCX) APPLTYPE(USER) USERID(mqgemusr)
APPLTAG(MQGem Software MO71)  APPLTYPE(USER) USERID(mqgemusr)
APPLTAG(MQGem Software MQSCX) APPLTYPE(USER) USERID(mqgemusr)

Depths of Local Queues

When listing local queues to discover the depths of messages on them, you might use the following command.

DISPLAY QLOCAL(*) WHERE(CURDEPTH GT 0)

This would return you the TYPE attribute even though you have only asked for QLOCALs and the TYPE attribute isn’t conveying anything helpful. If you issue this command on a z/OS queue manager, you will also always be returned the QSGDISP attribute, even if you are not running a queue manager in a Queue Sharing Group and the value of that attribute is always QSGDISP(QMGR).

QUEUE(SYSTEM.CHANNEL.SYNCQ)            TYPE(QLOCAL) QSGDISP(QMGR) CURDEPTH(10)
QUEUE(SYSTEM.CHLAUTH.DATA.QUEUE)       TYPE(QLOCAL) QSGDISP(QMGR) CURDEPTH(3)
QUEUE(SYSTEM.CLUSTER.REPOSITORY.QUEUE) TYPE(QLOCAL) QSGDISP(QMGR) CURDEPTH(3)
QUEUE(SYSTEM.DURABLE.SUBSCRIBER.QUEUE) TYPE(QLOCAL) QSGDISP(QMGR) CURDEPTH(1)
QUEUE(SYSTEM.HIERARCHY.STATE)          TYPE(QLOCAL) QSGDISP(QMGR) CURDEPTH(2)
QUEUE(SYSTEM.RETAINED.PUB.QUEUE)       TYPE(QLOCAL) QSGDISP(QMGR) CURDEPTH(4)

I can make this display more concise by using modifiers to remove the attributes that I don’t want to see.

DISPLAY QLOCAL(*) WHERE(CURDEPTH GT 0) -TYPE -QSGDISP

QUEUE(SYSTEM.CHANNEL.SYNCQ)            CURDEPTH(10)
QUEUE(SYSTEM.CHLAUTH.DATA.QUEUE)       CURDEPTH(3)
QUEUE(SYSTEM.CLUSTER.REPOSITORY.QUEUE) CURDEPTH(3)
QUEUE(SYSTEM.DURABLE.SUBSCRIBER.QUEUE) CURDEPTH(1)
QUEUE(SYSTEM.HIERARCHY.STATE)          CURDEPTH(2)
QUEUE(SYSTEM.RETAINED.PUB.QUEUE)       CURDEPTH(4)

Channel Status

There are quite a number of attributes returned on DISPLAY CHSTATUS, and many of them for very good reason. However, sometimes you want a more concise view of only what you are currently looking to display. Rather than removing each of these many attributes individually by name, you can remove all of them at once and then add back in the ones you actually want to see with the ‘+’ (plus) modifier. Here’s an example of that.

DISPLAY CHSTATUS(*) -ALL +CHANNEL,RQMNAME,LSTMSGDA,LSGMSGTI

CHANNEL(TO.QM3) LSTMSGDA(2023-08-22) LSTMSGTI(17.05.52) RQMNAME(QM3)
CHANNEL(TO.QM4) LSTMSGDA(2023-08-22) LSTMSGTI(17.05.52) RQMNAME(QM4)
CHANNEL(TO.QM2) LSTMSGDA(2023-08-22) LSTMSGTI(17.05.52) RQMNAME(QM2)
CHANNEL(TO.QM1) LSTMSGDA(2023-08-22) LSTMSGTI(17.05.17) RQMNAME(QM4)
CHANNEL(TO.QM1) LSTMSGDA(2023-08-22) LSTMSGTI(17.05.17) RQMNAME(QM2)
CHANNEL(TO.QM1) LSTMSGDA(2023-08-22) LSTMSGTI(17.05.14) RQMNAME(QM3)

Multiple modifiers to add/remove

If you have lots of similarly named attributes to add or remove from your display command output, you can use the # pattern matcher. For example, on channel objects there are several EXIT names, all containing the word “EXIT”. You can remove all those from the output with one modifier, thus:

DISPLAY CHANNEL(*) ALL -#EXIT

I’m sure you have your favourite displays that have attributes you wish you could hide. Well now you can. Use a command modifier to remove any attributes you don’t want displayed to you. Or completely re-design your command output by removing everything and then adding in only those attributes you wish to see.

Remember that if you end up with quite a long command, you can make a synonym to save you having to type it in again.

---

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.