+

Search Tips | Advanced Search

What's changed in Version 9.2.0

Changes to functions and resources since IBM MQ Version 9.1.0 are described in this section. Review these changes before upgrading queue managers to the latest product version and decide whether we must plan to make changes to existing applications, scripts, and procedures before starting to migrate your systems.

IBM MQ Version 9.2.0 includes enhancements that were previously delivered in the CD releases of IBM MQ Version 9.1.0 through IBM MQ Version 9.1.5, along with some enhancements that are new at IBM MQ Version 9.2.0:

  • Changes that are new to Long Term Support (LTS) users at IBM MQ Version 9.2.0 are indicated by a dark blue icon
  • Changes that are new to Continuous Delivery (CD) users at IBM MQ Version 9.2.0 are indicated by a light blue icon


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

From IBM MQ Version 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 the application. However, the sample source code is still not included in these packages.

The genmqpkg command used to build a tailor made package with the subset of files needed for the application is extended so that the repackaging can now be done programmatically as well as interactively. This means that we 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.


Reduction in the number of XMS.NET dynamic link libraries

From IBM MQ Version 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
  • Three policy dynamic link libraries:

    • policy.8.0.IBM.XMS.dll
    • policy.9.0.IBM.XMS.dll
    • policy.9.1.IBM.XMS.dll


Support for .NET Core 3.1

From IBM MQ Version 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 Use IBM MQ classes for XMS .NET Standard.


Change to minimum required version of .NET Framework

From IBM MQ Version 9.2.0, to run IBM MQ classes for .NET Framework we 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 Version 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 Version 9.2.0 extends this to other programming languages. For more information, see Specify the application name in supported programming languages.


New IGNSTATE parameter for runmqsc START and STOP commands

From IBM MQ Version 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 we 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 we are using a IBM MQ Version 9.2.0 or later client, the values displayed for MQCNO_RECONNECT and MQCNO_RECONNECT_Q_MGR are the effective reconnect options. If we 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 Version 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 Version 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 Monitor 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 Version 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.


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

AMQP channels have an MCAUSER attribute, which we 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 Version 9.2.0, the MCAUSER user ID setting is only supported for user IDs up to 12 characters in length. From IBM MQ Version 9.2.0, the 12 character limit is removed.


Support for converting between CCSIDs 37 and 500

From IBM MQ Version 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 Version 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 Version 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 Eclipse level for IBM MQ Explorer

From Version 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 Version 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 Install and uninstall IBM MQ Explorer as a stand-alone application on Linux and Windows.


Reduction in the number of default objects

From IBM MQ Version 9.2.0 the number of default objects has been reduced by one, from 84 to 83.


Migrating uniform clusters to Version 9.1.5 or later

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


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

IBM MQ Version 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 Version 9.2.0, the fteStartAgent command returned either 0 for success or 1 for any type of failure. From IBM MQ Version 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 Version 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 Version 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 Version 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 Version 9.0

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

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


Improvements in performance to queue manager shutdown times

From IBM MQ Version 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).


Change to trigger monitor shutdown code

From IBM MQ Version 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 Version 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 Version 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 Version 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 Version 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, we 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 Enable 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 Version 9.2.0 and how to change this, see CipherSpec order in TLS handshake.


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 Enable CipherSpecs.


Changes to the tracing of the AMQR and MQXR services

From IBM MQ Version 9.2.0 we 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 Version 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 Version 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 Version 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 IBM MQ for z/OS UNIX System Services (USS) 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 we 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 IBM MQ for z/OS USS 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.


Removal of IBM MQ for z/OS enablement modules

From IBM MQ for z/OS Version 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, we should start setting the QMGRPROD attribute as part of migrating to Version 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, we should start setting the AMSPROD attribute as part of migrating to Version 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 Version 9.1.3 onwards and product usage recording with IBM MQ for z/OS products for more information.


Changes to the sample security exit CSQ4BCX3

From IBM MQ Version 9.2.0, the sample security exit CSQ4BCX3 has been updated to support both the following methods of checking a user ID and password:

  • Use the RemoteUserIdentifier and RemotePassword pair from the MQCD structure
  • Use the CSPUserIdPtr and CSPPasswordPtr pair from the MQCSP structure.

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.

For more information, see Use 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 Version 9.2.0, if we are using a Java Security Manager with MQIPT, we 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 Version 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 Version 9.2.0. To configure and administer MQIPT, edit the mqipt.conf configuration file and use the mqiptAdmin command, as described in Administer MQIPT by using the command line.

Parent topic: What's new and changed in IBM MQ Version 9.2.0


Related concepts


Related information

Last updated: 2020-10-04