What's new in IBM MQ 9.2.0 for Multiplatforms - base and Advanced entitlement

Uniform clusters

Uniform clusters are a specific pattern of an IBM MQ cluster that provides applications with a highly available and horizontally scaled collection of queue managers. When an application interacts with a uniform cluster as a single group, the queue managers work together to maintain an even balance of application instances across the cluster, including across queue manager maintenance and restarts. Automatic balancing across a set of clustered queue managers is supported for applications written in C, JMS, IBM MQ .NET, and XMS .NET. For more information, see About uniform clusters.

Application balancing is done at the application instance level. An application instance is a group of related connections identified within the queue manager by a shared connection tag.

Single set of configuration files

A single set of configuration files can be defined once and used to deploy multiple queue managers into the uniform cluster, ensuring the configuration is consistent across them. You have various options to help you configure uniform clusters. You can:

• Apply automatic configuration from an MQSC script at startup.
• Apply automatic configuration from an INI script at startup.
• Use additional qm.ini file stanzas to assist automatic cluster configuration.
• Provide an input file to runmqsc; see Running MQSC commands from text files for more details.

Application resource monitoring

You can display the status of one or more applications, and application instances, connected to a queue manager, cluster, or a uniform cluster by using the DISPLAY APSTATUS MQSC command or the Inquire Application Status and Inquire Application Status (Response) PCF commands. This information allows you to monitor and troubleshoot application balancing.

You can monitor usage statistics for each application that you specify by adding the STATAPP class to the amqsrua command. You can use this information to help you understand how your applications are being moved between queue managers and identify any anomalies. For more information, see Monitoring system resource usage by using the amqsrua command.

JSON format client channel definition table

The JSON format for the client channel definition table (CCDT) gives various improvements over the existing binary format CCDT, including the ability to define duplicate channel definitions of the same name. This is a client-side feature (that is, you need an IBM MQ 9.2.0 client, not an IBM MQ 9.2.0 queue manager). For more information, see Configuring a JSON format CCDT.

Inclusion of IBM MQ Internet Pass-Thru

IBM MQ Internet Pass-Thru (MQIPT) is a utility that can be used to implement messaging solutions between remote sites across the internet. In IBM MQ 9.2.0, MQIPT is a fully-supported optional component of IBM MQ that you can download from IBM Fix Central for IBM MQ. MQIPT has previously been available as support pack MS81.

The following changes have been made to MQIPT since version 2.1 of the support pack:

• The supplied Java runtime environment (JRE) has been upgraded from Java 7 to Java 8, to match the JRE version supplied with IBM MQ.
• The SSL 3.0, TLS 1.0, and TLS 1.1 protocols are disabled by default. The only cryptographic protocol that is enabled by default is TLS 1.2. To enable protocols that are disabled, follow the procedure in Enabling deprecated protocols and CipherSuites.
• Support for IBM Network Dispatcher has been removed.
• 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.
• All sample files supplied with MQIPT are now located under a new directory called samples in the MQIPT installation directory.
• The CommandPort property has been removed from the sample configuration file mqiptSample.conf to improve security. This means that when using the sample configuration, MQIPT does not listen on a command port for commands issued by the mqiptAdmin command. To allow MQIPT to be administered remotely using the mqiptAdmin command, change the configuration file to specify a value for the CommandPort or SSLCommandPort property. Review the security considerations in Other security considerations before enabling an MQIPT command port.

For more information about MQIPT, see IBM MQ Internet Pass-Thru.

Enhanced protection of stored passwords in MQIPT

From IBM MQ 9.2.0, all passwords that are stored in the MQIPT configuration can be protected by encrypting the passwords using the mqiptPW command. IBM MQ 9.2.0 also introduces a new, more secure, protection method for passwords that are stored for use by MQIPT, and the ability for you to specify an encryption key that is used to encrypt and decrypt stored passwords. For more information, see Encrypting stored passwords.

Improved administration of MQIPT

The following new features of MQIPT in IBM MQ 9.2.0 allow easier and more secure administration of MQIPT using the mqiptAdmin command.

• Local instances of MQIPT can be administered using the mqiptAdmin command without the need for MQIPT to listen on a command port. The mqiptAdmin command must be run under the user ID that was used to start the MQIPT instance. Alternatively, on AIX® and Linux®, the root user can be used.
• MQIPT can be configured to authenticate administrative commands received by a command port. If remote command authentication is enabled, users of the mqiptAdmin command must enter the correct access password, specified in the AccessPW property in the MQIPT configuration, whenever an administrative command is issued using a command port.
• MQIPT can be configured to listen for administrative commands using a command port that is secured by TLS. This uses encryption to protect data sent between the mqiptAdmin command and the MQIPT instance being administered, including the access password if MQIPT is configured to require authentication for commands received by the command port. The TLS command port can be configured in addition to the unsecured command port that is available in previous versions of MQIPT.
• A local address can be specified to restrict connections to either the unsecured or the TLS command port to those from a specific network interface. This can be used, for instance, to prevent remote administration of MQIPT, while allowing different users on the local machine to use the command port to administer MQIPT.

For more information about administering MQIPT using the mqiptAdmin command, see Administering MQIPT by using the command line.

Transport Layer Security (TLS) 1.3 support for a range of protocols

IBM MQ 9.2.0 supports Transport Layer Security (TLS) 1.3 for a range of protocols. TLS 1.3 can be used for connections between queue managers and for C, C++, IBM MQ classes for Java, and IBM MQ classes for JMS client applications.

Support for TLS 1.3 for Java and JMS client applications is provided when using Java 11.

New CipherSpecs for TLS 1.3

The new CipherSpecs for TLS 1.3 that IBM MQ 9.2.0 provides are described in Enabling CipherSpecs. (For a list of these CipherSpecs, see the TLS 1.3 CipherSpecs section in Table 1.) All the new CipherSpecs work both with RSA and Elliptic Curve certificates.

For ease of configuration and future migration, IBM MQ 9.2.0 also provides a set of alias CipherSpecs including ANY_TLS12, ANY_TLS12_OR_HIGHER, and ANY_TLS13_OR_HIGHER among others. Migrating existing security configurations to use an alias CipherSpec means that you can adapt to cipher additions and deprecations without needing to make further invasive configuration changes in the future. Adding an alias CipherSpec to message channel agent channels, MQI, Java and .NET clients, and cluster channels means that you can:

• Configure TLS channel security without needing to know a long complicated IBM MQ specific CipherSpec string.
• Adapt without any configuration change to use new ciphers, and handle deprecation of weak ciphers. This feature is particularly useful within clusters.

For more information about the alias CipherSpecs, see Enabling CipherSpecs. (For a list of these CipherSpecs, see the Alias CipherSpecs section in Table 1.) See also SSLCIPH, and Migrating existing security configurations to use an alias CipherSpec.

To use TLS 1.3 or TLS 1.3 alias CipherSpecs, the JRE running your Java or JMS application must support TLS 1.3.

Note: When using earlier CipherSpecs on a queue manager that has TLS 1.3 enabled through a server qm.ini property or a client mqclient.ini property, which is the default setting on a new queue manager, there are some changes that you should be aware of.

In accordance with the TLS 1.3 specification, many earlier CipherSpecs are disabled and cannot be enabled by use of the existing configuration options. These include:

• All SSLv3 CipherSpecs
• All RC2 or RC4 CipherSpecs
• All CipherSpecs with an encryption key size of less than 112 bits

To restore previous behavior, TLS 1.3 can be disabled as described in Using TLS 1.3 in IBM MQ.

Provision for a list of acceptable TLS CipherSpecs

From IBM MQ 9.2.0, you can provide a custom list of ordered and enabled CipherSpecs that IBM MQ is permitted to use. For more information on how to configure a custom list, see Providing a custom list of ordered and enabled CipherSpecs on Multiplatforms.

For more information about CipherSpec ordering, see CipherSpec order.

TLS Handshake Transcript

IBM MQ 9.2.0 adds support for the TLS handshake transcript available from the GSKit cryptographic provider. This functionality is available on Distributed platforms that utilize IBM MQ both in the queue manager and client. To view the TLS handshake transcript, GSKit and GSKit trace must be enabled and a TLS handshake must fail. The transcript will then be collected and written out as part of the amqrmppa or client application trace file.

TLS 1.3 on IBM i

The availability of TLS 1.3 on IBM MQ is dependent on the availability of TLS 1.3 in the underlying IBM i operating system. For details on what IBM i versions support TLS 1.3 and how to enable it, see System TLS support for TLSv1.3.

IBM MQ 9.2.0 introduces version 2 of the REST API. This version increase applies to the administrative REST API, messaging REST API, and MFT REST API. This version increase changes the resource URL that is used for the REST API. The URL prefix for the resource URLs at version 2 is the following URL:

https://host:port/ibmmq/rest/v2/

The following REST API resources are not available in version 2:

• GET subscription
• GET channel
• POST queue
• PATCH queue
• GET queue
• DELETE queue

You can use the MQSC resource URL as an alternative to using these version 1 REST API resources.

For example, before IBM MQ 9.2.0 the MQSC command could be sent to the /admin/action/qmgr/{qmgrName}/mqsc resource in the following format:

{
  "type": "runCommand",
  "parameters": {
    "command": "DEFINE CHANNEL(NEWSVRCONN) CHLTYPE(SVRCONN)"
}

From IBM MQ 9.2.0, you can send the command in the following JSON format:

{
   "type": "runCommandJSON",
   "command": "define",
   "qualifier": "channel",
   "name": "NEWSVRCONN",
   "parameters": {
      "chltype": "svrconn"
   }
}

From IBM MQ 9.2.0, the following enhancements are available with the JSON format MQSC REST API:

• The following commands are now supported:
  • DISPLAY CONN(connectionID) TYPE (HANDLE)
  • DISPLAY CONN(connectionID) TYPE (*)
  • DISPLAY CONN(connectionID) TYPE (ALL)
• Single quotation marks are automatically escaped. You no longer need to use an additional single quotation mark to specify a single quotation mark in an attribute value.
• In the SET POLICY command, the SIGNER and RECIP attributes are now list attributes. Instead of specifying a string value for these attributes, you now use a JSON array. This change enables you to specify multiple values for the SIGNER and RECIP within a single command.
• Enhanced MQSC syntax error checking is now available. When an MQSC syntax error is detected in the JSON input, instead of returning a 200 response and the MQSC error in the response body, a 400 response is returned with a new error message indicating where the syntax error occurred.

Changes to tracing and logging on IBM MQ Bridge to Salesforce

IBM MQ 9.2.0 introduces additional configuration options that permit two major classes of additional topology, and changes to the way in which tracing and logging work on IBM MQ Bridge to Salesforce. For more information, see Additional configuration options for IBM MQ Bridge to Salesforce and runmqsfb (run IBM MQ Bridge to Salesforce) for details of the changes to this command.

Secure password encryption for IBM MQ Bridge to Salesforce

IBM MQ 9.2.0 provides additional security options for the IBM MQ Bridge to Salesforce, including options for how passwords are stored. For more information, see runmqsfb (run IBM MQ Bridge to Salesforce).

IBM MQ 9.2.0 introduces the EphemeralPrefix, which defines the location that data ephemeral to the queue manager should go, such as queue manager operating system sockets, allowing the AIX and Linux domain sockets to be placed on a non-mounted file system in a Red Hat® OpenShift® environment. For more information, see Configurable ephemeral directory.

Message-driven bean problem resolution

From IBM MQ 9.2.0, the maxSequentialDeliveryFailures activation specification property defines the maximum number of sequential message delivery failures to a message-driven bean (MDB) instance that the resource adapter tolerates, before pausing the MDB. For more information, see IBM MQ message-driven bean pause in WebSphere® Liberty.

Full Liberty XA support with client channel definition tables

When using WebSphere Liberty 18.0.0.2 onwards, with IBM MQ 9.2.0, you can make use of queue manager groups within the client channel definition table (CCDT) in conjunction with XA transactions. This means that it is now possible to make use of workload distribution and availability, provided by queue manager groups, whilst maintaining transaction integrity. For more information, see Full Liberty XA support with client channel definition tables.

This is a client-side feature, that is, you need an IBM MQ 9.2.0 resource adapter, not an IBM MQ 9.2.0 queue manager.

Ability to browse messages on a queue

IBM MQ 9.2.0 introduces the ability to browse messages on a queue by using the messaging REST API:

• You can use the /messaging/qmgr/{qmgrName}/queue/{queueName}/message resource with an HTTP GET to browse the next message on the queue. For more information, see GET /messaging/qmgr/{qmgrName}/queue/{queueName}/message.
• You can use the /messaging/qmgr/{qmgrName}/queue/{queueName}/messagelist resource with an HTTP GET to view a list of messages on the queue. For more information, see GET /messaging/qmgr/{qmgrName}/queue/{queueName}/messagelist.

Enhanced REST messaging performance with connection pools

To optimize the performance of the messaging REST API, connections to IBM MQ queue managers are pooled. That is, instead of each REST request creating, using, and destroying its own connection, each REST request uses a connection from a connection pool. By default, 20 connections are available for each queue manager pool. You can change the maximum number of pooled connections and the default behavior of the messaging REST API when all connections are in use by using the setmqweb properties command. For more information, see Configuring the messaging REST API.

Publish messages to topics with the messaging REST API

From IBM MQ 9.2.0, you can publish messages to a specified topic by using the messaging REST API. You can use the /messaging/qmgr/{qmgrName}/topic/{topicString}/message resource with an HTTP POST to publish a message to the topic. For more information, see POST /messaging/qmgr/{qmgrName}/topic/{topicString}/message.

.NET Core support Windows and Linux

From IBM MQ 9.2.0, IBM MQ supports .NET Core on IBM MQ .NET and XMS .NET on Windows and Linux.

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

Support for development of .NET Core applications on macOS

IBM MQ 9.2.0 supports the development of .NET Core applications on macOS. Once developed, these applications can be run supported on either Windows or Linux environments. For more information, see Developing IBM MQ .NET Core applications on macOS.

Simplified creation of .NET Core applications

IBM MQ 9.2.0 adds .NET project templates to Microsoft Visual Studio, enabling you to write your applications more quickly. For more information, see Using the IBM MQ .NET project template and Using the IBM MQ XMS .NET project template.