What's changed in IBM MQ 9.2.0

IBM MQ C redistributable client packages extended to include elements required to build applications

From IBM MQ 9.2.0, the IBM MQ C redistributable client packages include the elements required to build the application that is the header files and copybooks. This simplifies application development process as it means that you no longer need to do a full installation of IBM MQ components in order to get started with developing your application. However, the sample source code is still not included in these packages.

The genmqpkg command that you can use to build a tailor made package with the subset of files needed for your application is extended so that the repackaging can now be done programmatically as well as interactively. This means that you can embed the rebuilding of the redistributable client into an automated development pipeline for onwards processing.

For more information, see Redistributable clients and Installation considerations for redistributable clients.

Improved error reporting when HOME is set to a directory that cannot be accessed

The ${HOME}/.mqm directory is created by the queue manager when using an unregistered or non-installed version of IBM MQ such as the redistributable client. For more information, see Limitations and other considerations for redistributable clients and IBM MQ file system permissions applied to /var/mqm.

From IBM MQ 9.2.0, the IBM MQ code has been modified so that a more appropriate error message is displayed if there is a problem writing to the HOME directory. The code path that previously led to a SEGV failure has also been corrected.

Reduction in the number of XMS.NET dynamic link libraries

From IBM MQ 9.2.0, the number of XMS.NET dynamic link libraries has been significantly reduced, to a total of five.

Support for .NET 6 applications using IBM MQ classes for .NET Standard and IBM MQ classes for XMS .NET Standard

From IBM MQ 9.2.0, Microsoft.NET Core 3.1 is the minimum required version for running IBM MQ classes for .NET Standard and IBM MQ classes for XMS .NET Standard.

From IBM MQ 9.2.0 Fix Pack 25, IBM MQ supports .NET 6 applications using IBM MQ classes for .NET Standard and IBM MQ classes for XMS .NET Standard. If you are using a .NET Core 3.1 application, you can run this application with a small edit in the csproj file, setting the targetframeworkversion to "net6.0", without any recompilation required.

For more information, see Installing IBM MQ classes for .NET Standard and Installing IBM MQ classes for XMS .NET Standard.

Change to minimum required version of .NET Framework

From IBM MQ 9.2.0, to run IBM MQ classes for .NET Framework you must install Microsoft.NET Framework V4.6.2. For more information, see Installing IBM MQ classes for .NET Framework.

Update to IBM MQ and Microsoft .NET mapping table for IBM MQ managed .NET client

From IBM MQ 9.2.0, the IBM MQ and Microsoft .NET mapping table for the IBM MQ managed .NET client has been updated to include the TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 CipherSpecs. This update means that the correct SSL/TLS protocol version is proposed to the server by the client so that the client can connect to a queue manager via a TLS enabled channel using these CipherSpecs. For more information, see CipherSpec mappings for the managed .NET client.

Custom application identification

In addition to the existing ability to choose an application name on Java or JMS client applications, IBM MQ 9.2.0 extends this to other programming languages. For more information, see Specifying the application name in supported programming languages.

New IGNSTATE parameter for runmqsc START and STOP commands

From IBM MQ 9.2.0, it is possible to specify what the return code from runmqsc START and STOP commands should be in the case where the object being started or stopped is already in the desired state. This makes it easier to write runmqsc scripts that give the same result when they are executed multiple times. The object types that IGNSTATE applies to are: CHANNEL, LISTENER, and SERVICE.

For more information about how you use this attribute, see START CHANNEL and STOP CHANNEL.

Change to displayed values for MQCNO_RECONNECT and MQCNO_RECONNECT_Q_MGR in DISPLAY CONN command

The DISPLAY CONN command displays connection information for applications connected to a queue manager. Two displayed CONNOPTS parameter options are MQCNO_RECONNECT and MQCNO_RECONNECT_Q_MGR.

If you are using an IBM MQ 9.2.0 or later client, the values displayed for MQCNO_RECONNECT and MQCNO_RECONNECT_Q_MGR are the effective reconnect options. If you are using an earlier client version, the values displayed are whatever the application specifies, whether they are currently taking effect or not.

For more information, see DISPLAY CONN.

Name change for APPLNAMECHG value in DISPLAY APSTATUS command

From IBM MQ 9.2.0, the APPLNAMECHG value of the IMMREASN parameter of the DISPLAY APSTATUS command has been renamed APPNAMECHG.

TYPE response added to DISPLAY APSTATUS command

From IBM MQ 9.2.0, the MQSC command DISPLAY APSTATUS displays the TYPE of response, which is one of application (APPL), local (LOCAL), or queue manager (QMGR). For more information, see Monitoring application balancing.

The equivalent PCF command Inquire Application Status (MQCMD_INQUIRE_APPL_STATUS) also displays the type of response. For more information, see Inquire Application Status (Response).

Changes to the DISPLAY CONN command

From IBM MQ 9.2.0, there is a change in behavior for the DISPLAY CONN command, and the equivalent PCF, REST API, and IBM MQ Explorer output.

Removal of 12 character limit on MCAUSER user ID for AMQP channels on Windows

AMQP channels have an MCAUSER attribute, which you can use to set the IBM MQ user ID that all connections to that channel are authorized under (see MCAUSER setting on a channel). On Windows, before IBM MQ 9.2.0, the MCAUSER user ID setting is only supported for user IDs up to 12 characters in length. From IBM MQ 9.2.0, the 12 character limit is removed.

Support for converting between CCSIDs 37 and 500

From IBM MQ 9.2.0, support has been added for converting between CCSIDs 37 and 500 on the IBM MQ Appliance, Windows, Linux®, and macOS.

Changes for uniform clusters

In IBM MQ 9.2.0, when using a uniform cluster, it is possible to prevent the use of dynamic queues for applications that have connected with MQCNO_RECONNECT. Certain messaging patterns, particularly those that involve the use of dynamic queues, can cause problems in a uniform cluster because applications can be asked to reconnect at any time. To prevent the use of dynamic queues in a uniform cluster, set the environment variable AMQ_BLOCK_RECONN_DYN_QUEUES for every queue manager.

In IBM MQ 9.2.0, it is not possible to open cluster queues for output in a uniform cluster when the bind type in use is MQOO_BIND_ON_OPEN and the application has connected with the connect option MQCNO_RECONNECT or MQCNO_RECONNECT_Q_MGR. In some cases, applications may be using MQOO_BIND_ON_OPEN because it is the default option for cluster queues, but it may not be necessary for those applications. If that is the case and the messages semantics of MQOO_BIND_ON_OPEN are not required, change the bind type to one of the other bind options. The same behavior can be enabled for regular clusters by setting the environment variable AMQ_BIND_ON_OPEN_W_RECONNECT=NEVER on all queue managers that applications can connect to. If you wish to allow BIND_ON_OPEN to be used in conjunction with the MQCNO_RECONNECT or MQCNO_RECONNECT_Q_MGR options, set the environment variable AMQ_BIND_ON_OPEN_W_RECONNECT=ALLOW on all queue managers

Change to suppression of FFSTs for errors on initial communications flows

From IBM MQ 9.2.0, the capture of FFSTs when reporting AMQ9207E error messages on initial communications flows is suppressed by default. For more information, see Environment variables descriptions.

Change to Eclipse level for IBM MQ Explorer

From IBM MQ 9.2.0, IBM MQ Explorer is built on Eclipse 4.15.

Changes to delivery mechanism for updates to stand-alone IBM MQ Explorer

From IBM MQ 9.2.0, the stand-alone IBM MQ Explorer, previously known as SupportPac MS0T, is available as a stand-alone application from Fix Central. SupportPac MS0T is no longer available from the IBM download site. For information on how to install the stand-alone IBM MQ Explorer, see Installing and uninstalling IBM MQ Explorer as a stand-alone application on Linux and Windows.

Reduction in the number of default objects

From IBM MQ 9.2.0 the number of default objects has been reduced by one, from 84 to 83. This is because of the removal of the SYSTEM.MESSAGE.ASSOCIATION.QUEUE, previously used by the MQ Light web console. The console is no longer available in IBM MQ, so the default object has been removed.

Migrating uniform clusters to IBM MQ 9.1.5 or later

You need to be aware of certain restrictions when you migrate a uniform cluster from IBM MQ 9.1.4 to IBM MQ 9.1.5 or later. For more information, see Limitations and considerations for uniform clusters.

Additional InstallPATH option for the crtmqpkg command

From IBM MQ 9.2.0, when installing a maintenance update with the crtmqpkg command, you can use the additional option InstallPATH. The update is the installed directly into the directory specified by InstallPATH. For more information, see Multiple IBM MQ installations.

From IBM MQ 9.2.0 Fix Pack 2, the InstallPATH option is also available with the crtmqfp command. For more information, see Applying maintenance level updates on Linux using RPM.

Changes to the replicated data queue manager (RDQM) install packages

IBM MQ 9.2.0 introduces RHEL8 support as well as RHEL7 support for RDQM. The RHEL8 version installs Pacemaker 2, the RHEL7 version install Pacemaker 1. You now install RDQM and associated packages manually rather than by running an installation script. See Installing RDQM (replicated data queue managers).

See hardware and software requirements on Linux systems for more information.

New return codes returned by fteStartAgent command

Before IBM MQ 9.2.0, the fteStartAgent command returned either 0 for success or 1 for any type of failure. From IBM MQ 9.2.0, the fteStartAgent command can return four additional codes that indicate the nature of a failure. For more information, see fteStartAgent: start an MFT agent.

New RecoveryTimedOut transfer state for MFT agents

From IBM MQ 9.2.0, if a transfer recovery timeout is set for a transfer, the source agent moves the transfer into the RecoveryTimedOut state if transfer recovery times out. After the transfer has been resynchronized, the destination agent removes any part files that were created during the transfer and sends a completion message to the source agent.

For more information, see Transfer recovery timeout concepts and MFT agent transfer states.

Change to how MFT resource monitors initiate polling

Before IBM MQ 9.2.0, if a resource monitor performs a poll that takes longer than the polling interval, the next poll starts as soon as the current one finishes with no gap in between. If the items that are found during the first poll are still there when the second poll takes place, this could cause performance issues as it could have an effect on how quickly resource monitors submit work to an agent.

From IBM MQ 9.2.0, the way in which resource monitors initiate polling has been changed so that the resource monitor now uses the ScheduledExecutorService and initiates the next poll only after the completion of the previous poll plus the configured poll interval time. This means that there will now always be a gap in between the poll intervals, rather than having another poll starting straight away after the previous poll if the poll time was longer than the poll interval.

For more information, see MFT resource monitoring concepts.

Java EE database logger uses WebSphere Application Server traditional 9.0

From IBM MQ 9.2.0 the Java EE database logger uses WebSphere® Application Server traditional 9.0.

See Installing the Java EE database logger for MFT for more information.

Improvements in performance to queue manager shutdown times

Change to trigger monitor shutdown code

From IBM MQ 9.2.0, a normal shutdown when the queue manager is ending, of either a trigger monitor or client trigger monitor, returns a code of 0 rather than 10.

For more information, see runmqtmc and runmqtrm.

Target shutdown time option for endmqm command

From IBM MQ 9.2.0, you have the option to end the queue manager within a target time of a number of seconds that you specify.

For more information, see Stopping a queue manager and endmqm.

Removal of the ibm-mq-total-browse-size response header from the messaging REST API

From IBM MQ 9.2.0, the response header ibm-mq-total-browse-size is no longer returned when you browse a list of messages on a queue using the messaging REST API. That is, when you send a GET request to the /messaging/qmgr/{qmgrName}/queue/{queueName}/messagelist URL, the response no longer contains the ibm-mq-total-browse-size header.

For more information about GET /messaging/qmgr/{qmgrName}/queue/{queueName}/messagelist, see GET /messaging/qmgr/{qmgrName}/queue/{queueName}/messagelist.

Java exceptions no longer returned in REST JSON error responses

Previously, when an error response was returned by the REST API and the error was a Java error, the JSON response included details of the Java exception. From IBM MQ 9.2.0, this information is no longer returned. For more information about REST API error responses, see REST API error handling.

File encoding variable added to the jvm.options file for the mqweb server

From IBM MQ 9.2.0, the file encoding that is used to store user dashboard information for the IBM MQ Console is set to UTF-8. This setting ensures that user dashboard information in double-byte character sets is displayed correctly.

This update is made automatically only for new installations of IBM MQ where the IBM MQ data directory does not exist. If you upgrade your version of IBM MQ, or reinstall IBM MQ with an existing IBM MQ data directory, you must manually set the file encoding if you experience issues with the display of the user dashboard information.

The file encoding is set in the jvm.options file. For more information, see Tuning the mqweb server JVM.

CipherSpec order

The order of CipherSpecs is used when choosing between multiple possible CipherSpecs, for example when using one of the ANY* CipherSpecs. (For more information about ANY* CipherSpecs, see Enabling CipherSpecs, and for a list of these CipherSpecs, see the Alias CipherSpecs section in Table 1.) For this reason, the order of CipherSpecs presented during a TLS handshake by queue managers, C clients and unmanaged .NET clients has been changed to match the generally accepted preferred order, ensuring a more secure CipherSpec is chosen where possible. This may change what CipherSpec is selected during a TLS handshake compared to previous releases of IBM MQ.

Managed .NET clients and DataPower clients do not specify a single CipherSpec but present their own ordered CipherSpec list to IBM MQ. Prior to IBM MQ supporting alias CipherSpecs, it was necessary to configure the IBM MQ channel to specify a single CipherSpec based on the client’s CipherSpec ordering. With this change to CipherSpec ordering, it is possible that existing clients configured in this way fail to connect with an AMQ9631 error reported on the queue manager. It is recommended to no longer calculate the specific CipherSpec for the channel configuration and instead specify an Alias CipherSpec, for example ANY_TLS12_OR_HIGHER. The most secure available CipherSpec will then be negotiated between the client and the server.

For more information about the order of CipherSpecs that IBM MQ uses from IBM MQ 9.2.0 and how to change this, see CipherSpec order in TLS handshake.

GCM Cipher update

Following advice from IBM Global Security Kit (GSKit), a limit of 2^24.5 TLS records is now in place on GCM Ciphers. TLS communications that use GCM Ciphers, and do not reset the SSL key before the TLS records limit is reached, are terminated. For more information, see Enabling CipherSpecs.

mqm.gskit.rte library update

Additional GSKit libraries are used internally by the queue manager and client, and the mqm.gskit.rte file set is a dependency of both components. During installation IBM MQ automatically installs the mqm.gskit.rte library.

Changes to the tracing of the AMQR and MQXR services

From IBM MQ 9.2.0 you can trace selected areas of interest, as well as the entire service, for both the AMQR and MQXR services.

For more information, see Tracing the Advanced Message Queuing Protocol (AMQP) Service and Tracing the telemetry (MQXR) service.

Change to format of trace timestamps

From IBM MQ 9.2.0, the format of Windows trace timestamps has changed. See Example trace data for Windows for an example of the revised format.

Managed File Transfer for z/OS FMID moved to be part of IBM MQ for z/OS product installation

These changes apply to both IBM MQ Advanced for z/OS and IBM MQ Advanced for z/OS Value Unit Edition.

Prior to IBM MQ for z/OS 9.2, z/OS users with entitlement to IBM MQ Advanced for z/OS, IBM MQ for z/OS Value Unit Edition (VUE), or IBM MQ for z/OS Managed File Transfer for z/OS (MFT) had to perform a separate SMP/E install to obtain the MFT binaries using FMID HMF9110.

See Installing IBM MQ Advanced for z/OS for more information.

For information on how to migrate to the latest version of MFT see: Migrating a Managed File Transfer for z/OS installation to the next version of the product.

Removal of IBM MQ for z/OS enablement modules

From IBM MQ for z/OS 9.2.0, the enablement modules for Advanced Message Security for z/OS, IBM MQ Advanced for z/OS Value Unit Edition, and IBM MQ for z/OS Value Unit Edition are no longer shipped.

For Continuous Delivery, the enablement modules are no longer shipped from IBM MQ for z/OS 9.1.3 onwards.

For more information, see z/OS installation overview and Product usage recording with IBM MQ for z/OS products.

Changes to the sample security exit CSQ4BCX3

For more information, see IBM MQ for z/OS server connection channel.

The CONNSWAP parameter

The value of the CONNSWAP parameter is ignored by the CSQ6SYSP macro as applications are always made non-swappable during IBM MQ API calls..

For more information, see Using CSQ6SYP.

In addition, the DISPLAY SYSTEM MQSC command and Inquire System PCF command no longer return CONNSWAP information.

MQIPT Java security manager policy changes

From IBM MQ 9.2.0, if you are using a Java security manager with MQIPT, you must include additional javax.management.MBeanServerPermission, javax.management.MBeanPermission, and javax.management.MBeanTrustPermission permissions in the policy file. For the full list of permissions that are required to use a Java security manager with MQIPT, see Java security manager.

Toleration of invalid global property values in the MQIPT configuration

Previous versions of MQIPT terminated immediately if an invalid value for an property in the global section of the mqipt.conf configuration file was detected during startup or when refreshing MQIPT. From IBM MQ 9.2.0, invalid values for most properties in the global section are tolerated when refreshing the MQIPT configuration. If properties with invalid values in the global section are present when MQIPT is refreshed, a warning message is issued and the effective value of the property remains unchanged. This prevents invalid property values from causing an active instance of MQIPT to shut down when it is refreshed.

Removal of the IPT Administration Client

The IPT Administration Client graphical user interface has been removed. Previous versions of the IPT Administration Client cannot be used with MQIPT in IBM MQ 9.2.0. To configure and administer MQIPT, edit the mqipt.conf configuration file and use the mqiptAdmin command, as described in Administering MQIPT by using the command line.

Changes to connection sharing by JMS applications

If applications are configured as reconnectable, channel instances can only be shared between related JMS objects, that is a JMS Connection and its related JMS Sessions. This might require additional channel instances to be configured to support such applications.

For example, if an application uses a single JMS Connection and a single JMS Session, and the channel used has SHARECNV equal to 10, previously up to five instances of the application could share a single channel instance. This is still the case if the application is not configured to be reconnectable, but if the application is configured as reconnectable, each application instance will require its own channel instance, so five channel instances in total would be needed.

For more information, see Sharing a TCP/IP connection in IBM MQ classes for JMS.