What's changed in IBM MQ 9.3.0

Change to location of JAAS login files

From IBM MQ 9.3.0, the location of the JAAS login files has changed to &MQ_INSTALL_DIRECTORY&/ amqp/samples/jaas.

For earlier versions of IBM MQ, the location is &MQ_INSTALL_DIRECTORY&/ amqp/samples/samples

For more information, see Creating and using AMQP channels, Location of telemetry logs, error logs, and configuration files, and JAAS login module not called by the telemetry service.

Support for .NET 6

IBM MQ 9.3.0 adds support for .NET 6.

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.3.0, to run IBM MQ classes for .NET Framework or IBM MQ classes for XMS .NET Framework, you must install Microsoft.NET Framework V4.7.2. This is a change from IBM MQ 9.2 where the minimum required version was V4.6.2.

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

Changes to Bouncy Castle JAR file names

From IBM MQ 9.3.0, the names of the Bouncy Castle JAR files bundled with the product have changed. For example, bcprov-jdk15on.jar has changed to bcprov-jdk15to18.jar. For more information, see IBM MQ classes for JMS relocatable JAR files and IBM MQ classes for Java relocatable JAR files.

Improved toString() methods for some objects in IBM MQ classes for JMS

The com.ibm.mq.jms.MQConnection and com.ibm.mq.jms.MQSession objects implement javax.jms.Connection and javax.jms.Session respectively. They now have toString() methods which return key information about the underlying connection to IBM MQ.

The resulting string is in JSON format and contains fields as follows:

ObjectId

As a className and hexadecimal identifier

ConnectionId

In hexadecimal form

ConnectionMode

As specified at connection time

Host

Only applicable for client connections, but might be shown for bindings

Port

Only applicable for client connections, but might be shown for bindings

QueueManager

As specified at connection time

ResolvedQueueManager

Possibly different to QueueManager if a CCDT was used

The undocumented object produced by ConnectionFactory.createContext() essentially wraps a Connection and a Session object. Its toString() method produces a String representing a JSON object containing:

ObjectId

As a className and hexadecimal identifier

Connection

The toString() representation of the Connection

Session

The toString() representation of the Session

This change means that applications must now include the org.json.jar file shipped with the product on their CLASSPATH.

Improved toString() methods for some objects in the IBM MQ resource adapter

Connections, Sessions and Contexts generated in the IBM MQ resource adapter wrap their IBM MQ classes for JMS equivalents, and the toString() methods on them will produce information including the toString() representations of the wrapped IBM MQ classes for JMS objects.

Improved toString() methods for some objects in IBM MQ classes for Java

The toString() method for com.ibm.mq.MQQueueManager in IBM MQ classes for Java also produces a string in JSON format and containing fields as follows:

ObjectId

As a className and hexadecimal identifier

ConnectionId

In hexadecimal form

ConnectionMode

As specified at connection time

Host

Only applicable for client connections, but might be shown for bindings

Port

Only applicable for client connections, but might be shown for bindings

QueueManager

As specified at connection time

ResolvedQueueManager

Possibly different to QueueManager if a CCDT was used

This change means that applications must now include the org.json.jar file shipped with the product on their CLASSPATH.

Default authentication mode for IBM MQ classes for Java and IBM MQ classes for JMS client applications

IBM MQ classes for Java and IBM MQ classes for JMS applications that use client transport can be configured to use either MQCSP or compatibility mode to supply authentication information when connecting to an IBM MQ queue manager.

Before IBM MQ 9.3.0, the default authentication mode is MQCSP in applications that use IBM MQ classes for Java, and compatibility mode in applications that use IBM MQ classes for JMS.

From IBM MQ 9.3.0, the default authentication mode is MQCSP for both applications that use IBM MQ classes for Java, and applications that use IBM MQ classes for JMS. The methods that can be used to select a specific authentication mode, and which methods take precedence, has also been clarified.

For more information about connection authentication in IBM MQ Java clients, and how to select a specific authentication mode, see Connection authentication with the Java client.

These changes might cause the authentication method that is used by some Java client applications to change when the IBM MQ classes for Java or IBM MQ classes for JMS are upgraded to IBM MQ 9.3.0. This might cause applications that previously connected successfully to a queue manager to fail to connect with reason code 2035 (MQRC_NOT_AUTHORIZED). Review the information in Connection authentication with the Java client before migrating the IBM MQ classes for Java or IBM MQ classes for JMS to IBM MQ 9.3.0.

Changes to JMS/Java applications affecting applications connecting via TLS

A defect was found within JMS and Java applications when generating a server name indication (SNI) header for TLS connections. The defect meant that JMS and Java applications were not converting IBM MQ channel names to a SNI address in accordance with the rules defined in How IBM MQ provides multiple certificates capability.

Change of behavior for the managed .NET client when using a CCDT with queue manager grouping

Before IBM MQ 9.3.0, there is a difference in behavior between the managed .NET client and the IBM MQ Java and C clients when using a CCDT with queue manager grouping. When a CCDT file contains a queue manager group of three queue managers and three explicit CLNTCONNs to the same three queue managers and the application provides "*" as the queue manager, C and Java clients return MQRC_Q_MGR_NAME_ERROR. However, the managed .NET client uses the first available CLNTCONN and, if none are available, it then uses the queue manager grouped CLNTCONN.

From IBM MQ 9.3.0, the .NET client behaves in the same way as the C and Java clients and returns the MQRC_Q_MGR_NAME_ERROR. For more information, see Using a client channel definition table with .NET.

Change to error returned if MQCSP user ID and password length is exceeded

From IBM MQ 9.3.0, if a user ID or password exceeds the length permitted, the error returned to indicate the authentication request failed is MQRC_CSP_ERROR. In earlier versions, the error returned is MQRC_NOT_AUTHORIZED. For more information, see CSPUserIdLength (MQLONG) for MQCSP and CSPPasswordLength (MQLONG) for MQCSP.

IBM Aspera faspio Gateway version upgraded

IBM MQ Advanced for z/OS Value Unit Edition 9.3.0 and IBM MQ Advanced for Multiplatforms 9.3.0 upgrade the version of the IBM Aspera® faspio Gateway to 1.3.0.

Change to automatic configuration from MQSC at startup

From IBM MQ 9.3.0, the way that the auto-configuration feature behaves has changed. All MQSC commands are completed before applications can connect to the queue manager. This ensures that a queue manager's configuration is up to date prior to applications connecting but may increase the time it takes applications to connect to a restarted queue manager. For more information, see Automatic configuration from an MQSC script at startup.

Value of the SYSTEM.MQSC.REPLY.QUEUE MAXDEPTH attribute increased

To ensure that a remotely connected runmqsc command can process the full results for each command, IBM MQ 9.3.0 increases the value of the MAXDEPTH attribute from 3000 to 999999999. IBM MQ 9.3.0 also changes the way in which the  WaitTime parameter of the  runmqsc command behaves, by setting the value of WaitTime as an expiry time for PCF request messages. For more information, see runmqsc.

ConnName of application connection included in queue accounting records

From IBM MQ 9.3.0, ConnName is included in queue accounting records as well as in MQI accounting records. Both Channel Name and ConnName are needed in queue accounting records in order to fully identify a client-connected application. For more information, see Queue accounting message data.

IBM MQ Operator 1.7.0 works with CP4I 2021.4

For IBM MQ 9.3.0 in containers, you can use IBM MQ Operator 1.7.0. This Operator works with IBM Cloud Pak® for Integration 2021.4.

Change to how IBM MQ Explorer is delivered

From IBM MQ 9.3.0, the IBM MQ Explorer feature is no longer included in the Server product on Windows or Linux x86_64. It is still available as a separate download for those platforms. For more information, see Installing and uninstalling IBM MQ Explorer as a stand-alone application on Linux and Windows. One external change is that the strmqcfg command has been removed.

Changes to Managed File Transfer log files

Change to MFT agent ioIdleThreadTimeout property on z/OS

From IBM MQ 9.3.0, this property does not apply to Managed File Transfer agents running on IBM MQ for z/OS.

In addition, FileIOWorker threads for MFT agents running on IBM MQ for z/OS no longer time out.

For more information, see The MFT agent.properties file.

New STOPPING state for MFT agents

If an agent is stopped in a controlled manner using the fteStopAgent command, then the agent does not accept any new managed transfer requests and waits for any in-progress transfers to complete before it actually shuts itself down. Before IBM MQ 9.3.0, the status of agent was shown as STOPPED as soon as the command was issued. IBM MQ 9.3.0 adds a new STOPPING state for Managed File Transfer agents that are stopped in a controlled manner with the fteStopAgent command. The addition of this new state helps to make it clear that an agent is still in a transient state, and therefore has not yet shut down and cannot yet be restarted. For more information, see MFT agent status values and Stopping an MFT agent.

Newline limitation removed from the messaging REST API

The messaging REST API no longer removes new-lines from the HTTP request body.

REST API now uses the WebSphere Liberty Profile jaxrs-2.1 feature

The REST API previously used the WebSphere® Liberty Profile jaxrs-1.1 feature to map URLs to Java code, and to parse incoming requests. The REST API has now migrated to the jaxrs-2.1 feature to maintain currency and remove some restrictions.

New and removed Cipher Suites in MQIPT

For more information about TLS support in MQIPT, see SSL/TLS support.

Changes to supplying a key repository location

From IBM MQ 9.3.0, the queue manager and client applications have been updated to allow you to use a full file path, including extension, when providing the location of a key repository. Prior to this IBM MQ expected you to supply a file path without the extension.

To facilitate migration, IBM MQ continues to support a file path without an extension. In this case IBM MQ verifies that the full file path has not been provided and, on detecting that no file exists, automatically appends .kdb to the supplied value.

For more information, see Changing the key repository location for a queue manager on IBM i.

Changes to the SSLKEYRPWD parameter of the CHGMQM command

From IBM MQ 9.3.0, the CHGMQM command has been updated so that when you provide key repository passwords through the SSLKEYRPWD parameter, the password is encrypted using the IBM MQ Password Protection system.

This uses the initial key set on the queue manager. You should run the CHGMQM command after upgrading to IBM MQ 9.3.0, or higher, and setting a unique initial key in the queue manager to ensure your key repository passwords are protected with the latest algorithm.

See CHGMQM for more information.

Changes to how FIPS mode is enabled in MQIPT

From IBM MQ 9.3.0, the IBMJCEPlusFIPS cryptographic provider should be used to provide FIPS-certified cryptography in MQIPT. To use the IBMJCEPlusFIPS cryptographic provider, specify the com.ibm.jsse2.usefipsProviderName=IBMJCEPlusFIPS Java system property. For more information about enabling FIPS mode in MQIPT, see Enabling FIPS mode in MQIPT.

Changes to queue sharing group (QSG) support

From IBM MQ for z/OS 9.3, a queue manager is supported only in queue sharing groups containing queue managers at version 9.1 (CD or LTS) or above. This means that if you try to start an IBM MQ for z/OS 9.3 queue manager in a QSG containing queue managers below this level, the queue manager will terminate with completion code X'6C6' and reason code X'00F50029'.

Supporting the changes in QSG support, the VERIFY QSG function of the CSQ5PQSG utility now issues the CSQU599I message if a QSG contains queue managers of a version unsupported by the version of IBM MQ for z/OS that the utility is run from.

Replacement tool for hosting an offline version of IBM Documentation

Previously, documentation hosted in IBM Knowledge Center could also be downloaded and installed offline in a customer-installable version of Knowledge Center called KC-CI. This tool was designed for use in a Dark Shop environment, or in any situation where you cannot access documentation on the Internet. For documentation hosted in IBM Documentation, an equivalent offline tool is now available. The new tool is called "IBM Documentation Offline". For more information, see IBM MQ 9.3 in the IBM Documentation Offline app.