[V9.2.0 Jul 2020][V9.2.0 Jul 2020]

What's changed in IBM MQ 9.2.0

Before upgrading your queue managers to the latest product version, review these changes to functions and resources since IBM® MQ 9.1.0 and decide whether you must plan to make changes to existing applications, scripts, and procedures before starting to migrate your systems.

IBM MQ 9.2.0 includes enhancements that were previously delivered in the CD releases of IBM MQ 9.1.0 through IBM MQ 9.1.5, along with some enhancements that are new at IBM MQ 9.2.0:
  • Changes that are new to Long Term Support (LTS) users at IBM MQ 9.2.0 are indicated by a dark blue icon Icon for IBM MQ 9.2.0 LTS
  • Changes that are new to Continuous Delivery (CD) users at IBM MQ 9.2.0 are indicated by a light blue icon Icon for IBM MQ 9.2.0 LTS
Client application changes
Command and configuration changes
IBM MQ Explorer changes
Installation and migration changes
[IBM MQ Advanced]Managed File Transfer changes
[IBM MQ Advanced]
Queue manager changes
REST API changes
Security changes
Tracing changes
[z/OS]IBM MQ for z/OS® changes
[z/OS]
IBM MQ Internet Pass-Thru changes
[V9.2.0 Jul 2020][Windows][Linux]

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.

[V9.2.0 Jul 2020][V9.2.0 Jul 2020]

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.

[V9.2.0 Jul 2020][UNIX, Linux, Windows, IBM i]

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.

The five dynamic link libraries are:
  • IBM.XMS.dll - includes all the national language messages
  • IBM.XMS.Comms.RMM.dll
  • [Windows]Three policy dynamic link libraries:
    • policy.8.0.IBM.XMS.dll
    • policy.9.0.IBM.XMS.dll
    • policy.9.1.IBM.XMS.dll
[V9.2.0 Jul 2020][V9.2.0 Jul 2020][Windows][Linux]

Support for .NET Core 3.1

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. For more information, see Installing IBM MQ classes for .NET Standard and Using IBM MQ classes for XMS .NET Standard.

[V9.2.0 Jul 2020][V9.2.0 Jul 2020][Windows]

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.

[V9.2.0 Jul 2020][Windows]

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.

[V9.2.0 Jul 2020][UNIX, Linux, Windows, IBM i]

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.

[V9.2.0 Jul 2020][UNIX, Linux, Windows, IBM i]

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.

[V9.2.0 Jul 2020][AIX, Linux, Windows]

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.

[V9.2.0 Jul 2020][AIX, Linux, Windows]

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.

[V9.2.0 Jul 2020][UNIX, Linux, Windows, IBM i]

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).

[V9.2.0 Jul 2020][AIX, Linux, Windows]

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.

Connections coming from either the REST API or IBM MQ Explorer, which previously appeared with an APPLTYPE of USER and a blank APPLDESC, now appear with an APPLTYPE of SYSTEM and an APPLDESC of:
IBM MQ REST API
For connections coming from the IBM MQ REST API.
IBM MQ Explorer
For connections coming from an IBM MQ Explorer.
[V9.2.0 Jul 2020][Windows]

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.

[V9.2.0 Jul 2020][MQ Appliance]

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.

[V9.2.0 Jul 2020][V9.2.0 Jul 2020][UNIX, Linux, Windows, IBM i]

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

[V9.2.0 Jul 2020][V9.2.0 Jul 2020]

Change to Eclipse level for IBM MQ Explorer

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

[Windows][Linux]

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.

[V9.2.0 Jul 2020][UNIX, Linux, Windows, IBM i]

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.

[UNIX, Linux, Windows, IBM i]

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.

[Linux]

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.

[V9.2.0.2 Mar 2021]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.

[V9.2.0 Jul 2020][V9.2.0 Jul 2020][IBM MQ Advanced][Linux]

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.

[V9.2.0 Jul 2020]

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.

[V9.2.0 Jul 2020][IBM MQ Advanced]

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.

[V9.2.0 Jul 2020][IBM MQ Advanced]

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.

[V9.2.0 Jul 2020][IBM MQ Advanced]

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.

[V9.2.0 Jul 2020]

Improvements in performance to queue manager shutdown times

From IBM MQ 9.2.0, in certain situations which previously could have caused an extended period between issuing the endmqm command, and the queue manager stopping, the shutdown period has been very significantly reduced.
Attention: This is a significant change in performance, therefore, IBM MQ applications and queue manager topologies that make assumptions about extended shutdown periods, might effectively see changes in behavior in some cases.

As an extreme example, in circumstances where remote SENDER channels would have been notified that the receiver was ending during a slower shutdown, this might now only be detected when the next message is sent (which could, as expected, result in loss of non-persistent messages if using the setting NPMSPEED HIGH).

[V9.2.0 Jul 2020][UNIX, Linux, Windows, IBM i]

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.

[V9.2.0 Jul 2020][UNIX, Linux, Windows, IBM i]

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.

[V9.2.0 Jul 2020]

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.

[V9.2.0 Jul 2020]

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.

[V9.2.0 Jul 2020]

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.

[V9.2.0 Jul 2020][V9.2.0 Jul 2020][z/OS][UNIX, Linux, Windows, IBM i]

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.

[V9.2.0 Jul 2020][V9.2.0 Jul 2020][Windows][Linux]

GCM Cipher update

Following advice from 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.

[V9.2.0 Jul 2020][UNIX, Linux, Windows, IBM i]

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.

[V9.2.0 Jul 2020][UNIX, Linux, Windows, IBM i]

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.

[V9.2.0 Jul 2020][Windows]

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.

[V9.2.0 Jul 2020][V9.2.0 Jul 2020][z/OS]

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.

From IBM MQ for z/OS 9.2, the MFT binaries are provided as part of the IBM MQ for z/OS base installation under FMID JMS9207, simplifying the install process.
Important: You still need to be entitled to one of 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 if you install FMID JMS9207.

See Installing Managed File Transfer for z/OS for more information.

Important effects of this change are that:
  1. The MFT binaries will be installed into an mqft directory inside the z/OS UNIX System Services (z/OS UNIX) Components directory, for example: /mqm/V9R2M0/mqft.
  2. The MFT bin directory moves under the mqft directory, for example: /mqm/V9R2M0/mqft/bin.
    Note: This might affect any scripts that you have, which run any of the fte* commands, for example fteStartAgent.
  3. The SBFGCMDS data set, which contains MFT JCL has been renamed to SCSQFCMD. However, the individual JCL members inside the data set have not been renamed
  4. The BFGCUSTM job in the SBFGCMDS data set now uses a value of BFG_PROD that is relative to the z/OS UNIX Components directory.
For a full list of the changes, see Changes caused by integrating IBM MQ Managed File Transfer for z/OS into the base product

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.

[V9.2.0 Jul 2020][z/OS]

Removal of IBM MQ for z/OS enablement modules

From IBM MQ for z/OS 9.1.3 onwards, 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.
Attention:
  • If your enterprise is using the enablement modules for either IBM MQ Advanced for z/OS Value Unit Edition, or IBM MQ for z/OS Value Unit Edition, you should start setting the QMGRPROD attribute as part of migrating to IBM MQ for z/OS 9.1.3 or later. Failure to do this results in the wrong Product ID being associated with usage of the IBM MQ product, which will affect accurate SCRT reporting.
  • If your enterprise is using the enablement module for Advanced Message Security, you should start setting the AMSPROD attribute as part of migrating to IBM MQ for z/OS 9.1.3 or later. Failure to do this prevents the queue manager starting up, and message CSQY024I will be issued.

See z/OS installation overview from IBM MQ for z/OS 9.1.3 onwards and product usage recording with IBM MQ for z/OS products for more information.

[V9.2.0 Jul 2020][z/OS]

Changes to the sample security exit CSQ4BCX3

From IBM MQ 9.2.0, the sample security exit CSQ4BCX3 has been updated to support both the following methods of checking a user ID and password:
  • Using the RemoteUserIdentifier and RemotePassword pair from the MQCD structure
  • Using the CSPUserIdPtr and CSPPasswordPtr pair from the MQCSP structure.

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

[V9.2.0 Jul 2020][z/OS]

The CONNSWAP parameter

The value of the CONNSWAP parameter is ignored by the CSQ6SYSP macro.

For more information, see Using CSQ6SYP.

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

[V9.2.0 Jul 2020][V9.2.0 Jul 2020]

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.

[V9.2.0 Jul 2020][V9.2.0 Jul 2020]

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.

[V9.2.0 Jul 2020][V9.2.0 Jul 2020]

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.