MQ 10 for z/OS has additional fields in its SMF data. While useful, they brought challenges to the mqsmfcsv program that a number of people use for formatting and then analysing MQ SMF records.
Introduction
The mqsmfcsv program might not be the most heavily downloaded program, but I know that it is considered essential by some. It turns MQ’s SMF records into CSV-formatted rows that can then be analysed in various ways. I wrote more about it here and here.
Generally, the only required maintenance is to add fields where the underlying SMF structures have been extended. For example, when MQ 9.4.5 was released, there were new elements in the QMST structure that reported OpenTelemetry operations associated with the IMS bridge.
New fields in MQ 10
One new set of fields in MQ 10 is what I’d consider a business-as-usual update. The QCST (Channel Status) structure has been extended to show the RemoteProduct and RemoteVersion values provided by the other end of the channel. That gives an easy way to identify old clients or queue managers that might be connecting to you. These are the same values, with the same meanings, as have been available for a while in MQI structures and MQSC commands.
A more interesting, and more pervasive, change is the addition of the QSG name to just about every record. That makes it much simpler to work out some of the relationships, and to do things like link activity that may be coming via multiple queue managers to the same shared queue. Without needing additional information to be provided separately about the system configuration.
One further change was needed because of the move to Version 10. Although the standard SMF header allocates 4 characters for a version number, MQ had only ever used 3 of these. And there was no way to put 10.0.0 in there, even in some encoded fashion. The choice was made to put the full version elsewhere (actually alongside the QSG name) in a new block. The version is now reported as VVRRMM, so we see “100000” for this release, with plenty of room for future MQ versions. And it does sort in the correct order with older versions.
While this is primarily an internal change to the record and the formatter, it shows up externally as a longer value than previously.
If you look at the regular version field in the raw SMF record, you can see it contains946. Which is not a real MQ version. And that number will continue to increment until it hits 999 by which time anyone reading this will probably not care. But a >=946 test is a useful indicator, and I ended up needing to use it a couple of times to work out what to show in the formatted data. Although there’s supposedly a flag bit to show if this extended version structure is present, not all SMF subtypes had the basic structure which contained that flag field! Hence the need to also test the 3 character version in places.
Handling mixed versions in mqsmfcsv
One problem that has always been latent in mqsmfcsv, but which MQ 10 makes more obvious, is how to process data that comes from multiple versions of MQ. Essentially, the first time a given record type/subtype is encountered, it prints the column names that correspond to that record’s structures. So if there is a mixed level of queue manager data, those headings may not cover all of the fields in newer versions of MQ.
Because extra fields tend to be added to the end of structures, this has not been a big issue previously. We might get data like this in a CSV file:
"A","B","C" # Headers created from old qmgrs
1,2,3 # Data from that old qmgr
1,2,3,4 # Data from a newer qmgr that has no associated heading
or alternatively, if the newer qmgr is seen first:
"A","B","C","D"
1,2,3,4
1,2,3 # Data from an older qmgr doesn't fill all known columns
This just-about-acceptable processing really doesn’t work with MQ 10 because the QSG name is now inserted nearer the front of the columns for consistency.
So not only is there a mismatch in the number of columns, there’s also an offset meaning data might appear in the “wrong” column:
LPAR,QMgr,QSG,MQ_Version,Authorisation_ID,Correl_ID,... "MV4A","MQ1O","SQ13",="100000","MARK ",="1BA22538E7E75C5C1BD46AE0", "H019","MQPC",="800","IMS ",="F0F2F3F6C2C3F1E4C4D6C340",
It now looks like we have a QSG called “800”, and a version of “IMS”. Clearly wrong.
Temporary solution
The initial temporary solution for mqsmfcsv was to treat this as an error.
Data contains records from different versions of MQ: 800 and 100000
Filter data to have a single version of MQ, then rerun the formatter.
If you were processing data from mixed levels of MQ, the data would have to be split by qmgr (or at least by version) before downloading and processing it.
I knew this approach would need to change, and I validated a new model with users.
Better solution
The latest version of mqsmfcsv (version 5.7.0) now prints ALL known fields for the current version of MQ, regardless of the input data. So SMF records from MQ 9.1 will show a QSG field even though it’s not in the real data. This ensures a complete set of the CSV headers (or DDL for building database tables).
Instead, these padding fields are given clear inappropriate values. Strings are set to dots, while integers become -1 and dates show as 1970.
So an MQ 10 queue manager that is not a member of a QSG will show an empty name. While an MQ 9 queue manager will always show a name of “….” regardless of whether it does or does not belong to a QSG.
If you really want to exclude the padding fields and you know that the input data is coming only from a single version of MQ, the command has a -f oldcolsonly option to revert to only showing the real columns. Any mixed version input will cause an error in this mode.
Will queries need to change
Possibly. But mostly not.
Most of the queries I’ve seen will not be affected by these padding entries. As they tend to be looking at data that has been produced by queue managers forever. But you may have some queries that look specifically at the newer metrics and you might then need to exclude anything coming from older qmgrs.
For example, if you want to count the number of OpenTelemetry operations that have been done with the IMS bridge, you would add something like
WHERE QMST.OTEL_IMS_BRIDGE_SPANS >= 0
Because three related fields were added at the same time to that structure, the example WHERE expression would filter for all of them – you don’t need multiple AND filters. But you might prefer the clarity.
Sample Data
A small amount of test data is available in the Github repository, generated from an MQ 10 system. You can use that in conjunction with the other test files to explore some of the new fields and how the multiple version options work.
Summary
The new information available with MQ 10 was created because of user requests. Although the updates to the formatting program were not quite as straightforward as some previous versions, I hope that people are now able to take advantage of these expanded metrics.
This post was last updated on July 1st, 2026 at 08:41 am